[opensuse] polluting the filesystem
Can someone explain what the pooint of this is? This is a new installation. I tried to cutomize the partioning, but leap didn't like it and wouldn't like me log in. So I just relented and wiped the drive clean with cfdisk and let it do what it wanted and this is what it does... ruben@stat15:~> df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 428K 16G 1% /dev/shm tmpfs 16G 2.3M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/sda3 21G 5.2G 14G 28% / /dev/sda3 21G 5.2G 14G 28% /var/lib/libvirt/images /dev/sda3 21G 5.2G 14G 28% /.snapshots /dev/sda3 21G 5.2G 14G 28% /var/tmp /dev/sda3 21G 5.2G 14G 28% /tmp /dev/sda3 21G 5.2G 14G 28% /var/spool /dev/sda3 21G 5.2G 14G 28% /var/opt /dev/sda3 21G 5.2G 14G 28% /var/lib/named /dev/sda3 21G 5.2G 14G 28% /var/lib/mysql /dev/sda3 21G 5.2G 14G 28% /var/lib/pgsql /dev/sda3 21G 5.2G 14G 28% /var/lib/mailman /dev/sda3 21G 5.2G 14G 28% /var/lib/mariadb /dev/sda3 21G 5.2G 14G 28% /var/crash /dev/sda3 21G 5.2G 14G 28% /usr/local /dev/sda3 21G 5.2G 14G 28% /srv /dev/sda3 21G 5.2G 14G 28% /opt /dev/sda3 21G 5.2G 14G 28% /boot/grub2/x86_64-efi /dev/sda3 21G 5.2G 14G 28% /boot/grub2/i386-pc /dev/sda3 21G 5.2G 14G 28% /var/log /dev/sda1 156M 4.6M 152M 3% /boot/efi /dev/sda4 909G 21G 889G 3% /home /dev/sdc1 2.8T 2.5T 277G 91% /run/media/ruben/FantomHD -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
This seems insane. I can't get useful information with this kind of bambardment ruben@stat15:~> mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,size=16340680k,nr_inodes=4085170,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) /dev/sda3 on / type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) debugfs on /sys/kernel/debug type debugfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) /dev/sda3 on /var/lib/libvirt/images type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/@/var/lib/libvirt/images) /dev/sda3 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@/.snapshots) /dev/sda3 on /var/tmp type btrfs (rw,relatime,space_cache,subvolid=276,subvol=/@/var/tmp) /dev/sda3 on /tmp type btrfs (rw,relatime,space_cache,subvolid=264,subvol=/@/tmp) /dev/sda3 on /var/spool type btrfs (rw,relatime,space_cache,subvolid=275,subvol=/@/var/spool) /dev/sda3 on /var/opt type btrfs (rw,relatime,space_cache,subvolid=274,subvol=/@/var/opt) /dev/sda3 on /var/lib/named type btrfs (rw,relatime,space_cache,subvolid=271,subvol=/@/var/lib/named) /dev/sda3 on /var/lib/mysql type btrfs (rw,relatime,space_cache,subvolid=270,subvol=/@/var/lib/mysql) /dev/sda3 on /var/lib/pgsql type btrfs (rw,relatime,space_cache,subvolid=272,subvol=/@/var/lib/pgsql) /dev/sda3 on /var/lib/mailman type btrfs (rw,relatime,space_cache,subvolid=268,subvol=/@/var/lib/mailman) /dev/sda3 on /var/lib/mariadb type btrfs (rw,relatime,space_cache,subvolid=269,subvol=/@/var/lib/mariadb) /dev/sda3 on /var/crash type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/var/crash) /dev/sda3 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=265,subvol=/@/usr/local) /dev/sda3 on /srv type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/srv) /dev/sda3 on /opt type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/opt) /dev/sda3 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache,subvolid=261,subvol=/@/boot/grub2/x86_64-efi) /dev/sda3 on /boot/grub2/i386-pc type btrfs (rw,relatime,space_cache,subvolid=260,subvol=/@/boot/grub2/i386-pc) /dev/sda3 on /var/log type btrfs (rw,relatime,space_cache,subvolid=273,subvol=/@/var/log) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro) /dev/sda4 on /home type xfs (rw,relatime,attr2,inode64,noquota) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100) /dev/sdc1 on /run/media/ruben/FantomHD type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime) On Mon, Mar 14, 2016 at 06:49:20AM -0400, Ruben Safir wrote:
Can someone explain what the pooint of this is?
This is a new installation. I tried to cutomize the partioning, but leap didn't like it and wouldn't like me log in. So I just relented and wiped the drive clean with cfdisk and let it do what it wanted and this is what it does...
ruben@stat15:~> df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 428K 16G 1% /dev/shm tmpfs 16G 2.3M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/sda3 21G 5.2G 14G 28% / /dev/sda3 21G 5.2G 14G 28% /var/lib/libvirt/images /dev/sda3 21G 5.2G 14G 28% /.snapshots /dev/sda3 21G 5.2G 14G 28% /var/tmp /dev/sda3 21G 5.2G 14G 28% /tmp /dev/sda3 21G 5.2G 14G 28% /var/spool /dev/sda3 21G 5.2G 14G 28% /var/opt /dev/sda3 21G 5.2G 14G 28% /var/lib/named /dev/sda3 21G 5.2G 14G 28% /var/lib/mysql /dev/sda3 21G 5.2G 14G 28% /var/lib/pgsql /dev/sda3 21G 5.2G 14G 28% /var/lib/mailman /dev/sda3 21G 5.2G 14G 28% /var/lib/mariadb /dev/sda3 21G 5.2G 14G 28% /var/crash /dev/sda3 21G 5.2G 14G 28% /usr/local /dev/sda3 21G 5.2G 14G 28% /srv /dev/sda3 21G 5.2G 14G 28% /opt /dev/sda3 21G 5.2G 14G 28% /boot/grub2/x86_64-efi /dev/sda3 21G 5.2G 14G 28% /boot/grub2/i386-pc /dev/sda3 21G 5.2G 14G 28% /var/log /dev/sda1 156M 4.6M 152M 3% /boot/efi /dev/sda4 909G 21G 889G 3% /home /dev/sdc1 2.8T 2.5T 277G 91% /run/media/ruben/FantomHD
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dne pondělí 14. března 2016 6:49:20 CET, Ruben Safir napsal(a):
Can someone explain what the pooint of this is?
This is a new installation. I tried to cutomize the partioning, but leap didn't like it and wouldn't like me log in. So I just relented and wiped the drive clean with cfdisk and let it do what it wanted and this is what it does...
ruben@stat15:~> df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 428K 16G 1% /dev/shm tmpfs 16G 2.3M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/sda3 21G 5.2G 14G 28% / /dev/sda3 21G 5.2G 14G 28% /var/lib/libvirt/images /dev/sda3 21G 5.2G 14G 28% /.snapshots /dev/sda3 21G 5.2G 14G 28% /var/tmp /dev/sda3 21G 5.2G 14G 28% /tmp /dev/sda3 21G 5.2G 14G 28% /var/spool /dev/sda3 21G 5.2G 14G 28% /var/opt /dev/sda3 21G 5.2G 14G 28% /var/lib/named /dev/sda3 21G 5.2G 14G 28% /var/lib/mysql /dev/sda3 21G 5.2G 14G 28% /var/lib/pgsql /dev/sda3 21G 5.2G 14G 28% /var/lib/mailman /dev/sda3 21G 5.2G 14G 28% /var/lib/mariadb /dev/sda3 21G 5.2G 14G 28% /var/crash /dev/sda3 21G 5.2G 14G 28% /usr/local /dev/sda3 21G 5.2G 14G 28% /srv /dev/sda3 21G 5.2G 14G 28% /opt /dev/sda3 21G 5.2G 14G 28% /boot/grub2/x86_64-efi /dev/sda3 21G 5.2G 14G 28% /boot/grub2/i386-pc /dev/sda3 21G 5.2G 14G 28% /var/log /dev/sda1 156M 4.6M 152M 3% /boot/efi /dev/sda4 909G 21G 889G 3% /home /dev/sdc1 2.8T 2.5T 277G 91% /run/media/ruben/FantomHD
https://www.suse.com/documentation/sles-12/stor_admin/data/ sec_filesystems_major.html -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On 2016-03-14 11:49, Ruben Safir wrote:
Can someone explain what the pooint of this is?
This is a new installation. I tried to cutomize the partioning, but leap didn't like it and wouldn't like me log in.
I always use my own partitioning, I don't have any problem convincing the installer to do what /I/ want, not what he wants.
So I just relented and wiped the drive clean with cfdisk and let it do what it wanted and this is what it does...
ruben@stat15:~> df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 428K 16G 1% /dev/shm tmpfs 16G 2.3M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/sda3 21G 5.2G 14G 28% / /dev/sda3 21G 5.2G 14G 28% /var/lib/libvirt/images /dev/sda3 21G 5.2G 14G 28% /.snapshots /dev/sda3 21G 5.2G 14G 28% /var/tmp /dev/sda3 21G 5.2G 14G 28% /tmp /dev/sda3 21G 5.2G 14G 28% /var/spool /dev/sda3 21G 5.2G 14G 28% /var/opt /dev/sda3 21G 5.2G 14G 28% /var/lib/named /dev/sda3 21G 5.2G 14G 28% /var/lib/mysql /dev/sda3 21G 5.2G 14G 28% /var/lib/pgsql /dev/sda3 21G 5.2G 14G 28% /var/lib/mailman /dev/sda3 21G 5.2G 14G 28% /var/lib/mariadb /dev/sda3 21G 5.2G 14G 28% /var/crash /dev/sda3 21G 5.2G 14G 28% /usr/local /dev/sda3 21G 5.2G 14G 28% /srv /dev/sda3 21G 5.2G 14G 28% /opt /dev/sda3 21G 5.2G 14G 28% /boot/grub2/x86_64-efi /dev/sda3 21G 5.2G 14G 28% /boot/grub2/i386-pc /dev/sda3 21G 5.2G 14G 28% /var/log /dev/sda1 156M 4.6M 152M 3% /boot/efi /dev/sda4 909G 21G 889G 3% /home /dev/sdc1 2.8T 2.5T 277G 91% /run/media/ruben/FantomHD
So? What's the problem? That's what the installers does if you use the default btrfs filesystem on "/". Notice that it is a single partition, sdda3, plus another for efi and another for home. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 08:44 AM, Carlos E. R. wrote:
So? What's the problem?
That's what the installers does if you use the default btrfs filesystem on "/". Notice that it is a single partition, sdda3, plus another for efi and another for home.
I agree with Carlos, you should be in control. I use something like Knooppix on a new system to parition the disk. regualr readers will recall that I put everything except /boot on a LVM. If you want encryption, then this is a good approach, make the whole LVM encrypted! I then create the RootFS & /home and a bunch of other stuff I want to manage separately, like /opt. /usr/share, /var, /tmp/ /srv and /usr/local. Why, you may ask? Well it also makes upgrading easier :-) I can off-line any custom stuff in /home, /opt and /usr/local for the upgrade. I can easily purge /tmp. It also facilitates the way I do backups. But that's another matter and we've argued that point before. BtrFS is ... useful. But only in context. I don't see the facilities for multi=spindle being of value to me. The snapshot is useful for reversing updates ... maybe. If I were in a multi-user setting like an ISP and needed to be able to reverse user changes, the having /home on BtrFS would make sense. I don't so it doesn't. As it stands, the was openSuse manages repositories its actually easier to use Yast/Zypper to back up to a previous version of an application, so right now I don't see any benefit to BtrFS for me. In fact the next long weekend I plan to convert my RootFS to ext4. Easier with LVM than some other approaches. I think Ruben's complaint is that left to itself the installer created a lot of subvolumes and you really can't tell the space that they are each using from running a 'df'. A reason to dislike BtrFS? Well it was designed that way, which may be wrong. Which is why I created 'real' partitions (see above). The installer will honour them. But equally well, you can delete subvolumes. Yes you really do delete them just as if you had done a "rm -fr <subvolume>". Can you retroactive do what I've done? Create a LVM, create /var and move from the existing /var to /dev/vgmain/vVAR which is mounted at /mnt/disk/ using rsync, then removed the /var subvolume, edit /etc/fstab and away you go? Yes I've done that kind of thing and it has to be done in maintenance mode. Once again something like Knoppix or another LiveCD/LiveUSB is needed. Moving /dev/vgmain/vROOT to /dev/vgmain/vROOT4 is no different. What? oh yes it is. You need to update grub, better do a mkinitrd after that chroot trick I've mentioned previously. https://wiki.archlinux.org/index.php?title=Boot_debugging&oldid=337625#Repairing_with_Arch_live_CD YMMV. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 14:22, Anton Aylward wrote:
I think Ruben's complaint is that left to itself the installer created a lot of subvolumes and you really can't tell the space that they are each using from running a 'df'. A reason to dislike BtrFS? Well it was designed that way, which may be wrong. Which is why I created 'real' partitions (see above). The installer will honour them.
There are strong reasons to create all those "spaces" when using btrfs. One, is that when reverting an update by using that feature, you must not revert the logs and other information. Then for directories used for databases you should not use COW. Ie, it is for properly adjusting the settings on each directory, even if they are all in the same partition. So, yes, leave those spaces alone ;-) On the other hand, "df" doesn't know about btrfs peculiarities. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos, et al -- ...and then Carlos E. R. said... % % On 2016-03-14 14:22, Anton Aylward wrote: % % > designed that way, which may be wrong. Which is why I created 'real' % > partitions (see above). The installer will honour them. % % There are strong reasons to create all those "spaces" when using btrfs. ... % % So, yes, leave those spaces alone ;-) ... presuming, that is, that you are using btrfs. I read Anton's post ass saying that he *doesn't*. % % % On the other hand, "df" doesn't know about btrfs peculiarities. Indeed. I always whip up a 'dfx' alias to eXclude stuff I don't want when I just care about how much space is available where :-) % % -- % Cheers / Saludos, % % Carlos E. R. HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 14:47, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said...
% So, yes, leave those spaces alone ;-)
... presuming, that is, that you are using btrfs. I read Anton's post ass saying that he *doesn't*.
But Ruben, which is the OP and the case in point here, is ;-) You only get that "df" output when using btrfs. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos, et al -- ...and then Carlos E. R. said... % % On 2016-03-14 14:47, David T-G wrote: % > % > ...and then Carlos E. R. said... % % > % So, yes, leave those spaces alone ;-) % > % > ... presuming, that is, that you are using btrfs. I read Anton's post % > ass saying that he *doesn't*. % % But Ruben, which is the OP and the case in point here, is ;-) Ah. So "Hey, Ruben, don't mess up your config by following non-btrfs advice"? Yeah, now that makes sense. % % You only get that "df" output when using btrfs. Yep. % % -- % Cheers / Saludos, % % Carlos E. R. Thanks for the clarification & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Mar 14, 2016 at 10:00:45AM -0400, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % % On 2016-03-14 14:47, David T-G wrote: % > % > ...and then Carlos E. R. said... % % > % So, yes, leave those spaces alone ;-) % > % > ... presuming, that is, that you are using btrfs. I read Anton's post % > ass saying that he *doesn't*. % % But Ruben, which is the OP and the case in point here, is ;-)
Ah. So "Hey, Ruben, don't mess up your config by following non-btrfs advice"? Yeah, now that makes sense.
% % You only get that "df" output when using btrfs.
Yep.
The really fustrating part was when I tried to remove btfs and use xfs, the install failed, in that I couldn't log inot gdm. I know it is unfair, but I am feeling that the people making the installer have lost there handle on the software and it seems to be unpredicable. this kind of complexity is exactly the kind of thing that one doesn't need, especailly for an install with three partitions /swap / and /home (and now also /boot and /boot/EFI and /bios and this is really getting to be a PIA)
% % -- % Cheers / Saludos, % % Carlos E. R.
Thanks for the clarification & HAND
:-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruben Safir wrote:
The really fustrating part was when I tried to remove btfs and use xfs, the install failed, in that I couldn't log inot gdm. I know it is unfair, but I am feeling that the people making the installer have lost there handle on the software and it seems to be unpredicable.
Ruben, I never install on butterfs, and installing on xfs, ext4 works flawlessly. Installing on pre-formatted filesystems also works, although ISTR an issue with getting those added to fstab.
this kind of complexity is exactly the kind of thing that one doesn't need, especailly for an install with three partitions /swap / and /home (and now also /boot and /boot/EFI and /bios and this is really getting to be a PIA)
I agree, but such is life in an anarchy. -- Per Jessen, Zürich (5.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/14/2016 09:35 AM, Per Jessen wrote:
Ruben Safir wrote:
The really fustrating part was when I tried to remove btfs and use xfs, the install failed, in that I couldn't log inot gdm. I know it is unfair, but I am feeling that the people making the installer have lost there handle on the software and it seems to be unpredicable.
Ruben, I never install on butterfs, and installing on xfs, ext4 works flawlessly. Installing on pre-formatted filesystems also works, although ISTR an issue with getting those added to fstab.
this kind of complexity is exactly the kind of thing that one doesn't need, especailly for an install with three partitions /swap / and /home (and now also /boot and /boot/EFI and /bios and this is really getting to be a PIA)
I agree, but such is life in an anarchy.
Same here. I've put BTRFS into a two year time-out. I may look into it again in a couple years, but it adds nothing I need, induces complexity beyond reason, and after two data losses (one requiring re-install) its on my ban list. Systemd caused enough confusing crap to appear in mtab and fstab that the additions caused by BTRFS became unmanageable. I use ext4 for / (root) and xfs for /home and /data (both encrypted). -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 15:20, Ruben Safir wrote:
The really fustrating part was when I tried to remove btfs and use xfs, the install failed, in that I couldn't log inot gdm.
Not being able to login surely is not the fault of using XFS. You did something wrong. You could have asked here about the issue giving full details.
the kind of thing that one doesn't need, especailly for an install with three partitions /swap / and /home (and now also /boot and /boot/EFI and /bios and this is really getting to be a PIA)
When you see several partitions you do not understand their use, like bios, or efi, let the system create them then modify the rest that you do understand, like home or root. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 09:47 AM, David T-G wrote:
... presuming, that is, that you are using btrfs. I read Anton's post ass saying that he *doesn't*.
Well I didn't. I do, currently, use BtrFS for my RootFS. I long ago got rid of those sub-volumes. I've also turned off snapshotting. Soon, I'm going to convert the RootFS to ext4. I may even get a performance boost out of that, according to some speed trials :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Mar 14, 2016 at 02:42:53PM +0100, Carlos E. R. wrote:
On 2016-03-14 14:22, Anton Aylward wrote:
I think Ruben's complaint is that left to itself the installer created a lot of subvolumes and you really can't tell the space that they are each using from running a 'df'. A reason to dislike BtrFS? Well it was designed that way, which may be wrong. Which is why I created 'real' partitions (see above). The installer will honour them.
There are strong reasons to create all those "spaces" when using btrfs. One, is that when reverting an update by using that feature, you must not revert the logs and other information. Then for directories used for databases you should not use COW. Ie, it is for properly adjusting the settings on each directory, even if they are all in the same partition.
So, yes, leave those spaces alone ;-)
That is not nearly as important or frequently used as checking how much drive spacw i have or where something is mounted. It is information overload and a very poor design
On the other hand, "df" doesn't know about btrfs peculiarities.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 14:51, Ruben Safir wrote:
On Mon, Mar 14, 2016 at 02:42:53PM +0100, Carlos E. R. wrote:
That is not nearly as important or frequently used as checking how much drive spacw i have or where something is mounted.
It is information overload and a very poor design
Well, you are free to report a bug against df :-P -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 09:42 AM, Carlos E. R. wrote:
On 2016-03-14 14:22, Anton Aylward wrote:
I think Ruben's complaint is that left to itself the installer created a lot of subvolumes and you really can't tell the space that they are each using from running a 'df'. A reason to dislike BtrFS? Well it was designed that way, which may be wrong. Which is why I created 'real' partitions (see above). The installer will honour them.
There are strong reasons to create all those "spaces" when using btrfs. One, is that when reverting an update by using that feature, you must not revert the logs and other information. Then for directories used for databases you should not use COW. Ie, it is for properly adjusting the settings on each directory, even if they are all in the same partition.
So, yes, leave those spaces alone ;-)
I have come to think that this is a weak argument. I recall the ability to roll-back updates on mainframes-class machines and even some versions of AIX where IBM customers wanted the same capability as they had on the mainframes from IBM. But if the logic you are proposing is that wonderful then it applies more to the user space on /home! As I say, updates can be reverted (and logs of the forward action and backward action kept) because of the way openSuse repositories work. The granularity is quite large. But user-space is different. Its all very well to take daily (perhaps incremental) backups of user space under /home (perhaps to the cloud) but the reality is that period is too great for the majority of mistakes users make. They need something much more fine grained. I recall one DEC system where the editor gave you key-stroke by keystroke reversibility! (And YeeGods was it disk intensive. You could hear the disk plink echoing the keyboard plink!) I understand the arguments in favour of BtrFS. I've worked, as I said, on the mainframe-grade and mega-server grade machines where this idea comes from. However I cannot see it being a great benefit for workstations and in particular for workstations run by people who are not or who are not interested in being Uber-sysadmin-gurus.
On the other hand, "df" doesn't know about btrfs peculiarities.
This seems to be Ruben's primary complaint. I have to agree with him here. Once you could see where the system was consuming space with the 'df' command and do something about it. Now we've lost that granularity of inspection. I'd also mention that there were a lot of very good reasons for partitioning that ranged from security (of various forms), to reliability as well as manageability. Being able to mount nosuid and noexec as well as having different allocation strategies and hence different file system performance matched to the application context are just a few. In short, we've throw away a lot of useful stuff for the rather selective benefits that BtrFS offers. If you'd asked me before the winter I'd have said I was an supporter of BtrFS. But now I've played with XFS and done some more with ext4 and done it all under LVM, I'm not so sure. I can still see the benefits of BtrFS but I'm more aware that they are benefits only in context. I no longer think that context is relevant to me. I also think its not going to be relevant to a lot of other people who end up having it because the installer presents it as a default, as Ruben found. I don't expect people to follow me just because I say so. I do, however, suggest following Hagbard Celine's advice and evaluating your own context and make up your own mind about the benefits and costs. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 03/14/2016 09:42 AM, Carlos E. R. wrote:
On 2016-03-14 14:22, Anton Aylward wrote:
I think Ruben's complaint is that left to itself the installer created a lot of subvolumes and you really can't tell the space that they are each using from running a 'df'. A reason to dislike BtrFS? Well it was designed that way, which may be wrong. Which is why I created 'real' partitions (see above). The installer will honour them.
There are strong reasons to create all those "spaces" when using btrfs. One, is that when reverting an update by using that feature, you must not revert the logs and other information. Then for directories used for databases you should not use COW. Ie, it is for properly adjusting the settings on each directory, even if they are all in the same partition.
So, yes, leave those spaces alone ;-)
I have come to think that this is a weak argument.
I recall the ability to roll-back updates on mainframes-class machines and even some versions of AIX where IBM customers wanted the same capability as they had on the mainframes from IBM.
Yes, on z/OS (aka MVS), PTF's, APAR's and SYSMOD's are easily "rolled" on and off using SMP/E. Well, twenty years ago at least.
But user-space is different. Its all very well to take daily (perhaps incremental) backups of user space under /home (perhaps to the cloud) but the reality is that period is too great for the majority of mistakes users make.
Undo, Ctrl-Z and the daily backup has actually served me quite well for the last 30 years :-) -- Per Jessen, Zürich (5.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 14/03/2016 15:22, Anton Aylward a écrit :
This seems to be Ruben's primary complaint. I have to agree with him here. Once you could see where the system was consuming space with the 'df' command and do something about it. Now we've lost that granularity of inspection.
not really. We have other command that do the same btrfs fi show but this needs to be root, may be shouldn't df began to be less useful with the tmpfs. We have little need to know what is in tmpfs a solution should be to have a "-x" df option that exclude subvolumes? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/14/2016 10:35 AM, jdd wrote:
Le 14/03/2016 15:22, Anton Aylward a écrit :
This seems to be Ruben's primary complaint. I have to agree with him here. Once you could see where the system was consuming space with the 'df' command and do something about it. Now we've lost that granularity of inspection.
not really. We have other command that do the same
btrfs fi show
True but wrong headed. It means a script has to deal with an 'exception', determining the fstype first. Ok, not a insurmountable complication, but a complication that shouldn't be necessary. *NIX always worked by being 'regular'. It was the Giants, the monolithic OSes that needed all this 'exceptional' dealing. Like VMS, where the text files produced by the terminal editor, I found, were not the type of text file that the C compiler wanted. Why? Some idiotic view of 'optimization'. The reality is that it took more time in human frustration and workaround than was ever saved in CPU time because of this attitude towards 'optimization'.
but this needs to be root, may be shouldn't
Yeah, that become a deal killer! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 14/03/2016 16:22, Anton Aylward a écrit :
fstype first. Ok, not a insurmountable complication, but a complication that shouldn't be necessary. *
you are right, but may be it needs some time for me, I tend to install root with ext4, but my main install was default and it works jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 15:22, Anton Aylward wrote:
On 03/14/2016 09:42 AM, Carlos E. R. wrote:
So, yes, leave those spaces alone ;-)
I have come to think that this is a weak argument.
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that. What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs). It has nothing to do with the installer, nor with discussing if btrfs is good or not. IF you use btrfs, you have to create those many subvolumes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 06:43 PM, Carlos E. R. wrote:
On 2016-03-14 15:22, Anton Aylward wrote:
On 03/14/2016 09:42 AM, Carlos E. R. wrote:
So, yes, leave those spaces alone ;-)
I have come to think that this is a weak argument.
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs). It has nothing to do with the installer, nor with discussing if btrfs is good or not. IF you use btrfs, you have to create those many subvolumes.
no - they need to stop polluting the name space with inapropriate data. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 19:50, Ruben Safir wrote:
no - they need to stop polluting the name space with inapropriate data.
Again, if you think that way, don't tell us, and report the bug properly against df. See if they listen or tell you to code it yourself if you wish :-P But we can not help you. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 02:50 PM, Ruben Safir wrote:
On 03/14/2016 06:43 PM, Carlos E. R. wrote:
On 2016-03-14 15:22, Anton Aylward wrote:
On 03/14/2016 09:42 AM, Carlos E. R. wrote:
So, yes, leave those spaces alone ;-)
I have come to think that this is a weak argument.
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs). It has nothing to do with the installer, nor with discussing if btrfs is good or not. IF you use btrfs, you have to create those many subvolumes.
no - they need to stop polluting the name space with inapropriate data.
What exactly is inappropriate about subvolumes? df should not rely purely on data supplied by mtab and instead check to see if its listing a subvolume (subvol=/path/to or subvolid=XYZ). In other words df should be updated... -- Regards, Uzair Shamim
Carlos E. R. composed on 2016-03-14 19:43 (UTC+0100):
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs).
I changed .bashrc 1.5 years ago: alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup ' Is freespace on *mpfs or cgroup ever relevant to a human? The new df option should be for inclusion, not exclusion, making excluding them the default. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 14/03/2016 20:05, Felix Miata a écrit :
Carlos E. R. composed on 2016-03-14 19:43 (UTC+0100):
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs).
I changed .bashrc 1.5 years ago: alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup '
Is freespace on *mpfs or cgroup ever relevant to a human? The new df option should be for inclusion, not exclusion, making excluding them the default.
is there a way to exclude btrfs subvolumes? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/14/2016 04:03 PM, jdd wrote:
Le 14/03/2016 20:05, Felix Miata a écrit :
Carlos E. R. composed on 2016-03-14 19:43 (UTC+0100):
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs).
I changed .bashrc 1.5 years ago: alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup '
Is freespace on *mpfs or cgroup ever relevant to a human? The new df option should be for inclusion, not exclusion, making excluding them the default.
is there a way to exclude btrfs subvolumes?
jdd
Does this work for you? df | awk -F" " '!_[$1]++' -- Regards, Uzair Shamim
Le 14/03/2016 21:22, Uzair Shamim a écrit :
df | awk -F" " '!_[$1]++'
how can I use this in an alias (usually alias strings are between single quotes, but they are already used here) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/14/2016 05:41 PM, jdd wrote:
Le 14/03/2016 21:22, Uzair Shamim a écrit :
df | awk -F" " '!_[$1]++'
how can I use this in an alias (usually alias strings are between single quotes, but they are already used here)
thanks jdd
This seems to work on my system, you just have to escape the single quotes and add that $ at the start. alias test=$'df | awk -F" " \'!_[$1]++\'' -- Regards, Uzair Shamim
Le 14/03/2016 22:52, Uzair Shamim a écrit :
This seems to work on my system, you just have to escape the single quotes and add that $ at the start.
alias test=$'df | awk -F" " \'!_[$1]++\''
as you are much better as scripting than I am :-( you probably have a solution to the following goal. I want to addto the df message the one from btrfs for completeness that is add /usr/sbin/btrfs fi df -h / to the alias line, but what I tried didn't work :-( thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 03:56 AM, jdd wrote:
Le 14/03/2016 22:52, Uzair Shamim a écrit :
This seems to work on my system, you just have to escape the single quotes and add that $ at the start.
alias test=$'df | awk -F" " \'!_[$1]++\''
as you are much better as scripting than I am :-( you probably have a solution to the following goal.
I want to addto the df message the one from btrfs for completeness
that is add
/usr/sbin/btrfs fi df -h /
to the alias line, but what I tried didn't work :-(
thanks jdd
I don't know if you can one line it but here is a script to generate a report of df. Maybe not the cleanest solution but you can put it in a file and then set it in $PATH or as an alias. I'm not sure how to one line it.. #!/bin/bash df | awk -F" " '!_[$1]++' drives=$(df --type=btrfs | awk -F" " '!_[$1]++' | awk -F" " '{if (NR!=1) {print $6}}') for drive in $drives; do echo "" echo "== Status For Drive $drive ==" btrfs fi df $drive done -- Regards, Uzair Shamim
Le 15/03/2016 14:37, Uzair Shamim a écrit :
I don't know if you can one line it but here is a script to generate a report of df.
yes, this I can do :-) btrfs fi df $drive done
I need /usr/sbin/ to be able to run it as user, and I really don't mind having an error message ERROR: couldn't get space info - Inappropriate ioctl for device ERROR: get_df failed Inappropriate ioctl for device if the device is not btrfs thanks for your help jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 14 Mar 2016 21:03, jdd wrote:
Le 14/03/2016 20:05, Felix Miata a écrit :
Carlos E. R. composed on 2016-03-14 19:43 (UTC+0100):
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs).
I changed .bashrc 1.5 years ago: alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup '
Is freespace on *mpfs or cgroup ever relevant to a human? The new df option should be for inclusion, not exclusion, making excluding them the default.
is there a way to exclude btrfs subvolumes?
TL;DR: for btrfs keep the one with the shortest mountpoint path, per device. Roundabout: scripted, grep the devices you want and/or exclude from /proc/mounts, for devices that come up multiple times, exclude the bind mounts, for btrfs, keep only the one with the shortest mount point path. It's possible to do that with a awk one-liner. Feed that into df, make a alias / function or shell script for that. Sorry, away from machine with btrfs sub-vols, so no example. - Yamaban.
On 03/14/2016 02:43 PM, Carlos E. R. wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as plain old directories (which they are anyway). I know this is possible because I did it before I decided to move them off into separate file systems. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-14 23:03, Anton Aylward wrote:
On 03/14/2016 02:43 PM, Carlos E. R. wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as plain old directories (which they are anyway).
I know this is possible because I did it before I decided to move them off into separate file systems.
Of course you can replace them with real partitions. If you don't, you should keep the subvolumes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 06:06 PM, Carlos E. R. wrote:
On 2016-03-14 23:03, Anton Aylward wrote:
On 03/14/2016 02:43 PM, Carlos E. R. wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as plain old directories (which they are anyway).
I know this is possible because I did it before I decided to move them off into separate file systems.
Of course you can replace them with real partitions. If you don't, you should keep the subvolumes.
Please explain why one should keep the subvolumes? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/14/2016 07:20 PM, Anton Aylward wrote:
On 03/14/2016 06:06 PM, Carlos E. R. wrote:
On 2016-03-14 23:03, Anton Aylward wrote:
On 03/14/2016 02:43 PM, Carlos E. R. wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as plain old directories (which they are anyway).
I know this is possible because I did it before I decided to move them off into separate file systems.
Of course you can replace them with real partitions. If you don't, you should keep the subvolumes.
Please explain why one should keep the subvolumes?
Sorry. I should ask that another way. If subvolumes are that great, why aren't all the subdirectories of / subvolumes? "/etc" for example. Why not "/bin" and "/lib"? And why aren't there any secondary subvolumes, since that's not prohibited, things like "/usr/lib" which is pretty large, and "/usr/doc"? I've been told that subvolumes can be snapshotted, whereas folders can't be. That's not so in my experience. I had /etc/ (as well a /bin and /lib...) as a folder not a subvolume and still they were snapshotted when, for example, a zypper upgrade package brought about a change to config file. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dne pondělí 14. března 2016 19:35:55 CET, Anton Aylward napsal(a):
On 03/14/2016 07:20 PM, Anton Aylward wrote:
On 03/14/2016 06:06 PM, Carlos E. R. wrote:
On 2016-03-14 23:03, Anton Aylward wrote:
On 03/14/2016 02:43 PM, Carlos E. R. wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as plain old directories (which they are anyway).
I know this is possible because I did it before I decided to move them off into separate file systems.
Of course you can replace them with real partitions. If you don't, you should keep the subvolumes.
Please explain why one should keep the subvolumes?
Sorry. I should ask that another way. If subvolumes are that great, why aren't all the subdirectories of / subvolumes? "/etc" for example. Why not "/bin" and "/lib"?
And why aren't there any secondary subvolumes, since that's not prohibited, things like "/usr/lib" which is pretty large, and "/usr/doc"?
I've been told that subvolumes can be snapshotted, whereas folders can't be. That's not so in my experience. I had /etc/ (as well a /bin and /lib...) as a folder not a subvolume and still they were snapshotted when, for example, a zypper upgrade package brought about a change to config file.
If I can say, subvolumes can be excluded from snapshots. It doesn't make sense to keep e.g. content of /tmp in snapshots. Disabling COW is good for performance of DB (and there is no need for snapshoting anyway). So subvolumes can save a lot of space and have positive impact to performance. Of course, if You make Your custom layout which fits Your needs, good for You... -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On 03/14/2016 09:48 PM, Carlos E. R. wrote:
On 2016-03-15 00:20, Anton Aylward wrote:
Please explain why one should keep the subvolumes?
Several reasons. Some are configured differently. No COW for databases, no snapshot revert on logs...
That explains how to configure subvolumes, not why you should keep them rather than repalcing them with a mounted file system. On 03/15/2016 03:22 AM, Vojtěch Zeisek wrote:
If I can say, subvolumes can be excluded from snapshots. It doesn't make sense to keep e.g. content of /tmp in snapshots. Disabling COW is good for performance of DB (and there is no need for snapshoting anyway). So subvolumes can save a lot of space and have positive impact to performance. Of course, if You make Your custom layout which fits Your needs, good for You...
Sorry, that rings of "proof by assertion". Yes, it doesn't make sense to keep /tmp and databases under snapshots. In fact it may make more sense to put them on separate file systems more suited to the kind of activity. There's the case, for example, that /tmp should be a tmpfs since its often used for intermediate files or scratchpad. Some applications, such as compiling, where the parse tree is built in a temporary file, I've seen accelerated by this means. You say that subvolumes can save space but you don't say how or compared to what, and you say that they can have a positive impact on performance, again compared to what. or why. Dollar for Dollar, there are many other ways to get better performance: * move to a SSD or a faster SSD * move to a faster motherbaord, DDR4, add more memory * get a faster GPU, more local memory * move to a faster, perhaps more core CPU -- Intel now has a 20 core chip! -- Consider overclocking * move to a Series 4 late model kernel that has better locking * use a lighter DM with less 'eye candy' Any/all of those will, I think, offer a better systemic performance than anything changing file systems back and forth will do. The reality is that without a fabulous graphic engine Darktable eats CPU doing rendering; I suspect the same holds for web page rendering. In other areas, the real performance bottleneck is not the disk, its the network. But ultimately the delays in almost everything exist between the chair and the keyboard. And those seem to degrade with time. Personally I think the ability of ReiserFS to stuff small files (of which there are many under /etc for example) into odd places "saves space" very well. But there are many applications where large extents, often reserved ahead of time, make more sense. For example, I do a great deal of photograph work using Darktable. The camera's RAW files are of the order of 24Megabytes. I don't care about block size rounding errors of a couple of K. Once a RAW file is created it is never modified. It is read and and 'edits' are recorded in a sidebar file (<name>.xmp) and one or more images are produced as a result of the edit (as a .tiff, .gif, .jpg or .png). In some ways a kind of "overlay" file system where RAW file is on a ROMFS would make more sense. But in reality its more sutied to XFS. The Photonix survey keep showing that BtrFS doesn't perform well in certain areas, and other contributors to this forum have made very clear the advantages of, for example XFS for specific use cases. http://www.phoronix.com/scan.php?page=article&item=linux-41-filesystem&num=1 I'd so hoped that BtrFS would be the successor to ReiserFS, building on ideas that it had proven such as the btree techniques, and breaking away from the extN model. But it seems the designers wanted to absorb volume management and RAID into one glorious UberDiskFuntionaryMaster. (Perhaps that would be better in German with a couple of umlauts?) This should have warned us. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-15 13:18, Anton Aylward wrote:
On 03/14/2016 09:48 PM, Carlos E. R. wrote:
On 2016-03-15 00:20, Anton Aylward wrote:
Please explain why one should keep the subvolumes?
Several reasons. Some are configured differently. No COW for databases, no snapshot revert on logs...
That explains how to configure subvolumes, not why you should keep them rather than repalcing them with a mounted file system.
I never said that you could not replace them with another mount. It is up to you. What I said is not remove them if you are using btrfs for "/".
On 03/15/2016 03:22 AM, Vojtěch Zeisek wrote:
You say that subvolumes can save space but you don't say how or compared to what, and you say that they can have a positive impact on performance, again compared to what. or why.
Subvolumes are more space efficient that having separate partitions for each. A single partition for everything on the whole disk is always more efficient, simply because on each partition you have to leave some free space for use later, or not. And you have to guess how much space will be needed. If all is a single partition, there is a single, common, free space pool. That is more "efficient". Of course, again, you may choose to use separate partitions instead for whatever reasons. But that's your intentional and controlled choice as admin. For an automated install procedure that has to suit thousands of users, once the choice was made to use btrfs, it's becomes obvious there is advantages with using subvolumes. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlboLLIACgkQja8UbcUWM1zZvgEAj8hKnVonnFTwwinjNAgB8d2x n1FM1Vd+JSAYrYwiWQMBAI+2dY/BcQgqtLM38eE3U0ZU4kHKdLzI9QCo+NC+z8AI =DNQg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-03-15 13:18, Anton Aylward wrote:
On 2016-03-15 00:20, Anton Aylward wrote:
Please explain why one should keep the subvolumes? Several reasons. Some are configured differently. No COW for databases, no snapshot revert on logs... That explains how to configure subvolumes, not why you should keep
On 03/14/2016 09:48 PM, Carlos E. R. wrote: them rather than repalcing them with a mounted file system. I never said that you could not replace them with another mount. It is up to you.
What I said is not remove them if you are using btrfs for "/".
On 03/15/2016 03:22 AM, Vojtěch Zeisek wrote: You say that subvolumes can save space but you don't say how or compared to what, and you say that they can have a positive impact on performance, again compared to what. or why. Subvolumes are more space efficient that having separate partitions for each. A single partition for everything on the whole disk is always more efficient, simply because on each partition you have to leave some free space for use later, or not. And you have to guess how much space will be needed. If all is a single partition, there is a single, common, free space pool. That is more "efficient".
Of course, again, you may choose to use separate partitions instead for whatever reasons.
But that's your intentional and controlled choice as admin. For an automated install procedure that has to suit thousands of users, once the choice was made to use btrfs, it's becomes obvious there is advantages with using subvolumes.
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlboLLIACgkQja8UbcUWM1zZvgEAj8hKnVonnFTwwinjNAgB8d2x n1FM1Vd+JSAYrYwiWQMBAI+2dY/BcQgqtLM38eE3U0ZU4kHKdLzI9QCo+NC+z8AI =DNQg -----END PGP SIGNATURE----- I don't get what you are talking about, subvolumes are more efficient
On 03/15/2016 08:39 AM, Carlos E. R. wrote: than partitioning it manually yourself. In the end you end up with the same amount of available blocks, its just with subvols you can set quotas so you don't need to partition separate /var /var/log, etc, like Anton does...those days are over with -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 12:17 PM, sdm wrote:
I don't get what you are talking about, subvolumes are more efficient than partitioning it manually yourself. In the end you end up with the same amount of available blocks, its just with subvols you can set quotas so you don't need to partition separate /var /var/log, etc, like Anton does...those days are over with
You're missing the point that Carlos is making and you're also missing a number of points that I'm making. There mere fact that the automatic installer (a) sets up a separate partition for /home on a different file system and (b) easily offer the ability to create other partitions both show that final assertion to be false. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 11:39 AM, Carlos E. R. wrote:
Subvolumes are more space efficient that having separate partitions for each. A single partition for everything on the whole disk is always more efficient, simply because on each partition you have to leave some free space for use later, or not. And you have to guess how much space will be needed. If all is a single partition, there is a single, common, free space pool. That is more "efficient".
That's always been true, even back in the V6/V7 days of the late 1970s. In fact it was worse (and still is with the Ext file systems) when you have to make that same allocation "guess" between inode space and data space. We might consider the "All the disk devoted to a single file system" the "NULL Argument" of file systems. The number of arguments against it are many. Al to many issues to do with optimization and maintenance are non-linear, grow exponentially with the size of the file system. FSCK is a prime example of this. Yes, BtrFS has its own maintenance tools; do you imagine they are linear against size? I haven't seen metrics on this. Has anyone done any?
Of course, again, you may choose to use separate partitions instead for whatever reasons.
There are, once again, many. Quite apart from issues of "barriers" against abuse, a potential flaw of the single file system model that "quotas' are a weak protection against (and how many of us use quotas, want to manage them, especially on our personal workstations?), there are security issues and other matters. I've already touched on the issue that it may be beneficial to match the characteristics of the FS to the application running on it. Of course some people simply won't care one way or another, despite the dramatic results from Phoronix.
But that's your intentional and controlled choice as admin. For an automated install procedure that has to suit thousands of users, once the choice was made to use btrfs, it's becomes obvious there is advantages with using subvolumes.
Basically what you're saying is that most people are (a) to dumb to care, (b) to dumb to notice and (c) quite content to let other people make decisions for them. Well, current world-wide politics certainly supports the latter. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-15 17:52, Anton Aylward wrote:
On 03/15/2016 11:39 AM, Carlos E. R. wrote:
We might consider the "All the disk devoted to a single file system" the "NULL Argument" of file systems. The number of arguments against it are many.
Hey, I use many real partitions on my work systems, and of several different types. You don't have to tell me what the advantages are. However, that's not something YaST can setup on install for people. Those that want it that way must do the conscious choice and work. However, for the mane that use the default settings (or close to them), the fact is that btrfs is used, no matter if you, Anton, like it or not ;-P And for those using the default install, it is good and necessary™ to have subvolumes. It is as simple as that :-)
But that's your intentional and controlled choice as admin. For an automated install procedure that has to suit thousands of users, once the choice was made to use btrfs, it's becomes obvious there is advantages with using subvolumes.
Basically what you're saying is that most people are (a) to dumb to care, (b) to dumb to notice and (c) quite content to let other people make decisions for them. Well, current world-wide politics certainly supports the latter.
Hey, I let the installer make many choices that I don't care to change ;-) I change only those I really care about, for whatever reason. Maybe I want to change defaults, maybe I want to learn more. The rest, I simply want them to work reasonably well. In the past, I compiled the kernel locally. Nowdays, I do not care enough to do it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 04:35 PM, Anton Aylward wrote:
On 03/14/2016 07:20 PM, Anton Aylward wrote:
On 03/14/2016 06:06 PM, Carlos E. R. wrote:
On 2016-03-14 23:03, Anton Aylward wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that. No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as
On 03/14/2016 02:43 PM, Carlos E. R. wrote: plain old directories (which they are anyway).
I know this is possible because I did it before I decided to move them off into separate file systems. Of course you can replace them with real partitions. If you don't, you should keep the subvolumes. Please explain why one should keep the subvolumes?
Sorry. I should ask that another way. If subvolumes are that great, why aren't all the subdirectories of / subvolumes? "/etc" for example. Why not "/bin" and "/lib"?
And why aren't there any secondary subvolumes, since that's not prohibited, things like "/usr/lib" which is pretty large, and "/usr/doc"?
I've been told that subvolumes can be snapshotted, whereas folders can't be. That's not so in my experience. I had /etc/ (as well a /bin and /lib...) as a folder not a subvolume and still they were snapshotted when, for example, a zypper upgrade package brought about a change to config file.
Could it be the default btrfs subvol setup with openSUSE Leap & TW do it the way it does for quotas, also, and the paths they chose are a "cookie cutter" guess on what the SUSE devs thought were important, in addition to your comment about why don't other paths matter, too? imo the btrfs subvol default setup is too much, I don't use postgres or mariadb so I, in the end end up with about 8 total volumes (I have EFI and swap also ). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-15 00:35, Anton Aylward wrote:
Sorry. I should ask that another way. If subvolumes are that great, why aren't all the subdirectories of / subvolumes? "/etc" for example. Why not "/bin" and "/lib"?
And why aren't there any secondary subvolumes, since that's not prohibited, things like "/usr/lib" which is pretty large, and "/usr/doc"?
Because it is not necessary, and there is a penalty. I mentioned regressing an update via booting to an older snapshot. In this case, it is needed to revert changes in many places, like bin and lib and etc and /usr/lib, but not in /var/log, for instance. Or the journal directory. Perhaps not the data directories in root. I haven't studied the details, I'm not that interested. But the thing is, there are many directories that are treated equally, so no need to have them in separate subvolumes. Only those in which you need to do something different are made a subvolume. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/14/2016 07:20 PM, Anton Aylward wrote:
On 03/14/2016 06:06 PM, Carlos E. R. wrote:
On 2016-03-14 23:03, Anton Aylward wrote:
On 03/14/2016 02:43 PM, Carlos E. R. wrote:
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
No you don't. I removed subvolumes from my BtrFS RootFS a long time ago. I *chose* to have *some* of the replaced by mountable partitions. But it is still possible to have, for example, /tmp and /opt and /var as plain old directories (which they are anyway).
I know this is possible because I did it before I decided to move them off into separate file systems.
Of course you can replace them with real partitions. If you don't, you should keep the subvolumes.
Please explain why one should keep the subvolumes?
I am not a BTRFS expert by any means but let me try my best to explain it... For example, /var/lib/libvirt/images you can refer to this thread https://lists.opensuse.org/opensuse-factory/2016-01/msg00434.html Also /var/lib/mariadb is another example, it will have issues if you keep COW enabled as the database has small changes written to disk frequently and using COW causes performance issues in these cases[1]. This is why the sobvolume is mounted with the nodatacow (C) attribute: linux-n93l:~ # lsattr /var/lib/ ---------------- /var/lib/libvirt ---------------- /var/lib/mailman ---------------C /var/lib/mariadb ---------------- /var/lib/named ---------------C /var/lib/pgsql ... linux-n93l:~ # lsattr /var/lib/libvirt/ ---------------C /var/lib/libvirt/images ---------------- /var/lib/libvirt/boot ---------------- /var/lib/libvirt/filesystems ... These subvolumes also have the added benefit of preventing the snapshots that are auto configured for the / partition to snapshot the default DB or VM directories which helps prevent issues where BTRFS complains about a disk being full when in "reality" it isn't.
I've been told that subvolumes can be snapshotted, whereas folders can't be. That's not so in my experience. I had /etc/ (as well a /bin and /lib...) as a folder not a subvolume and still they were snapshotted when, for example, a zypper upgrade package brought about a change to config file.
The directories inside of / are all part of the root volume. Remember, snapshots for the / volume are not taken for the subvolumes! If you want to see subvolumes of a BTRFS partition you can use (I cut off a bunch of output, just kept interesting stuff): linux-n93l:~ # btrfs subvolume list / ID 257 gen 15202 top level 5 path @ ID 258 gen 75083 top level 257 path @/.snapshots ID 259 gen 69209 top level 258 path @/.snapshots/1/snapshot ID 267 gen 75074 top level 257 path @/var/lib/libvirt/images ... ID 816 gen 75162 top level 258 path @/.snapshots/355/snapshot ID 881 gen 59458 top level 258 path @/.snapshots/405/snapshot ID 882 gen 59458 top level 258 path @/.snapshots/406/snapshot ... You can see that the .snapshots directory is a subvolume (to prevent is from being taken in during a snapshot) and so is /var/lib/libvirt/images. Also notice that the snapshots themselves are actually just subvolumes that contain either a snapshot of file from some time or a link to the file on the FS: linux-n93l:~ # ls -l /.snapshots/405/snapshot/bin/ total 5244 lrwxrwxrwx 1 root root 13 Oct 14 10:44 arch -> /usr/bin/arch lrwxrwxrwx 1 root root 21 Dec 17 23:44 awk -> /etc/alternatives/awk lrwxrwxrwx 1 root root 17 Oct 14 10:44 basename -> /usr/bin/basename -rwxr-xr-x 1 root root 656552 Oct 25 05:04 bash ... If you try the same for a path that is a subvolume you should see something like this: linux-n93l:~ # ls -l /.snapshots/1/snapshot/var/lib/libvirt/ total 0 drwx--x--x 1 root root 0 Jan 14 15:02 boot drwxr-xr-x 1 root root 318 Feb 7 10:16 dnsmasq drwx--x--x 1 root root 0 Jan 14 15:02 filesystems drwxr-xr-x 1 root root 0 Dec 17 23:11 images drwx------ 1 root root 0 Jan 14 15:02 network drwxr-x--- 1 qemu qemu 56 Feb 5 22:51 qemu Hope that made some sense as to why those subvolumes are created. [1] https://wiki.archlinux.org/index.php/Btrfs#Copy-On-Write_.28CoW.29 -- Regards, Uzair Shamim
On 03/14/2016 07:55 PM, Uzair Shamim wrote:>
Hope that made some sense as to why those subvolumes are created.
No. I'm sure some on the list found you TL;DR interesting but it didn't tell me anything I didn't already know this time last year and completely failed to address any of my reasons why I'm, after a long stint and trying to promote BtrFS, finally giving up on it. In particular you don't address why mounted file systems should not be used instead of subvolumes. The benefit of BtrFS being one monolithic entity (rather like CICS was on the mainframe) subsuming all spindles, all space into one disk management system that also does file systems on the side can be thought of as "efficient (in the same way that CICS was compared to the UNIX approach of individual small things that "did one thing, only one thing and then got out of the way"[1]) is quite another matter. The argument of 'efficiency' this way is an old one that UNIX purists have always disputed in favour of the "just one thing" approach. Sadly, UNIX and Linux follow the macrokernel approach. https://www.reddit.com/r/linux/comments/487i3o/does_a_monolithic_kernel_arch... None of that debate really addresses what message passing micro-kernels CAN do. David Cheriton's https://en.wikipedia.org/wiki/David_Cheriton V System showed that you can spread a process over many machines on a network. Mind you, his microkernel was only a few hundred bytes so it was VERY fast. https://en.wikipedia.org/wiki/V_%28operating_system%29 [1] Under the IBM model, process creation was so expensive that it could only be done once at system boot. This mentality meant that the UNIX idea of 'light-weight' processes could not even be considered. At the time, UNIX was very revolutionary. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/03/2016 13:38, Anton Aylward a écrit :
In particular you don't address why mounted file systems should not be used instead of subvolumes.
there have been unnumerous discussions about how many partition have to be created. The default openSUSE that fits most people was two (/ and /home) then three when EFI wanted one. but then the question is: why do we need so many subvolumes? is it possible to resize subvolumes on the fly? I never wanted to use lvm, because it makes fixing problems difficult and much of my time is spent fixing not working machines, why should I have subvolumes? I have no database on my desktop (none that have meaning), not even on my server jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Отправлено с iPhone
15 марта 2016 г., в 17:20, jdd <jdd@dodin.org> написал(а):
but then the question is: why do we need so many subvolumes? is it possible to resize subvolumes on the fly?
All sub volumes share the same total filesystem space; they do not have "size". You can restrict space consumption of individual sub volumes using quota groups.-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/03/2016 16:13, Andrei Borzenkov a écrit :
Отправлено с iPhone
15 марта 2016 г., в 17:20, jdd <jdd@dodin.org> написал(а):
but then the question is: why do we need so many subvolumes? is it possible to resize subvolumes on the fly?
All sub volumes share the same total filesystem space; they do not have "size". You can restrict space consumption of individual sub volumes using quota groups.--
ok, so use of subvolumes remove the partition size of direct partitioning is this easier than lvm? I don't know thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-15 16:16, jdd wrote:
Le 15/03/2016 16:13, Andrei Borzenkov a écrit :
ok, so use of subvolumes remove the partition size of direct partitioning
is this easier than lvm? I don't know
Yes. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlboLRwACgkQja8UbcUWM1wPbQD+K0VTc/vh+ibaUnmFGsfLuUQE brqdKkk6sI4PLAh0syQA/iQFik6qwapgJbxpLTU5kWJ+fMHUg+5bbzj7PkvxHN8I =YG1W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 11:16 AM, jdd wrote:
ok, so use of subvolumes remove the partition size of direct partitioning
is this easier than lvm? I don't know
Easier for what? There are many circumstance where you want constraints such as fixed size partitions. Perhaps they don't apply to you or perhaps you don't care or perhaps you can't imagine that it would matter to someone else. But if you think LVM is about fixed size partitions then you don't understand LVM. I use LVM specifically because I don't want fixed size partitions ala fdisk. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/03/2016 18:04, Anton Aylward a écrit :
On 03/15/2016 11:16 AM, jdd wrote:
ok, so use of subvolumes remove the partition size *problem* of direct partitioning
is this easier than lvm? I don't know
Easier for what?
iy's the question. Is btrfs subvolume easier than lvm. I dunno.
There are many circumstance where you want constraints such as fixed size partitions.
may be, but also many times where this is a problem, and I have seen much more problems than solutions Perhaps they don't apply to you or perhaps you don't
care or perhaps you can't imagine that it would matter to someone else.
we a speaking of default install, here, everybody can do every thing anyway...
But if you think LVM is about fixed size partitions then you don't understand LVM. I use LVM specifically because I don't want fixed size partitions ala fdisk.
yes, and it's why I wonder is btrfs subvolumes are better or not. Subvolumes do not need at all fixed partitions, lvm allows easy changing. as someone said, when fixing problem each level of difficulty is an obstacle. With lvm it's much more difficult to know how the disk is used (let only because the computer owner do not know this himself), devices names are pretty hard to remember, partitioning needs the correct driver version to be read (and chance is you don't have it), etc. If lwm go through several disks, I simply refuse to try. jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 01:37 PM, jdd wrote:
Le 15/03/2016 18:04, Anton Aylward a écrit :
On 03/15/2016 11:16 AM, jdd wrote:
ok, so use of subvolumes remove the partition size *problem* of direct partitioning
is this easier than lvm? I don't know
Easier for what?
iy's the question. Is btrfs subvolume easier than lvm. I dunno.
For my purposes, as someone who cares and has the skills, the BtrFS subvolumes became irrelevant a long time ago.
There are many circumstance where you want constraints such as fixed size partitions.
may be, but also many times where this is a problem, and I have seen much more problems than solutions
I've seen other people with problems; I had the problems back in the 1980s myself with SCO UNIX and how to allocate the space of a 20G or 30G drive that needed a RAW partition for the database. It basically wasn't until I dealt with the Veritas Manager, the precursor of LVM, that I overcame this with the whole matter of being able to defer the issue and dynamically resize partitions on running systems. My experience is that inexperience, unwillingness to experiment and determine just what the tools and facilities can and can't do, unwillingness to push them around and learn how thy work, is the root cause of many problems people have with things like, for example, LVM.
Perhaps they don't apply to you or perhaps you don't care or perhaps you can't imagine that it would matter to someone else.
we a speaking of default install, here, everybody can do every thing anyway...
I've seen some people treat the default install as if it was some settings handed down God on Tablets of Stone, transposed to software. This gets back to what I said about letting other people make decisions, run your life for you. Sure, plonk a kid down in a bright red open top sportscar and he'd have a Let's see what this baby can do" attitude, so why no when it comes it a Linux installer. that was my attitude years ago, lets see what this installer can do! Defaults are for chickens.
But if you think LVM is about fixed size partitions then you don't understand LVM. I use LVM specifically because I don't want fixed size partitions ala fdisk.
yes, and it's why I wonder is btrfs subvolumes are better or not. Subvolumes do not need at all fixed partitions, lvm allows easy changing.
Subvolumes have nothing to do with partitioning, they are not analogous to partitioning. There is only one file system. Subvolumes are just a management tool. Think of them as markers on the map. "From here on in this policy applies".
as someone said, when fixing problem each level of difficulty is an obstacle. With lvm it's much more difficult to know how the disk is used (let only because the computer owner do not know this himself), devices names are pretty hard to remember, partitioning needs the correct driver version to be read (and chance is you don't have it), etc. If lwm go through several disks, I simply refuse to try.
None of what you've said except for that last sentence is true. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 11:05 AM, Anton Aylward wrote:
My experience is that inexperience, unwillingness to experiment and determine just what the tools and facilities can and can't do, unwillingness to push them around and learn how thy work, is the root cause of many problems people have with things like, for example, LVM.
This is all vary well and good, but some of us have work to do. Maybe I'm a little anal retentive, but when I have my working machine(s) and data structures all resident on external backup drives while I do an install over and over a few times to run experiments, its kind of like watching doctors play "hold my beer and watch this" while your kid is in the operating room on the heart-lung machine. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-15 18:37, jdd wrote:
Le 15/03/2016 18:04, Anton Aylward a écrit :
yes, and it's why I wonder is btrfs subvolumes are better or not. Subvolumes do not need at all fixed partitions, lvm allows easy changing.
as someone said, when fixing problem each level of difficulty is an obstacle. With lvm it's much more difficult to know how the disk is used (let only because the computer owner do not know this himself), devices names are pretty hard to remember, partitioning needs the correct driver version to be read (and chance is you don't have it), etc. If lwm go through several disks, I simply refuse to try.
That's the point. With LVM you need to learn how to resize the spaces, and spend time doing it. Yes, you do not have fixed partitions, you can add space when you need it. Not always subtract space. But the admin has to do it. Posibly tell LVM to give more space to such "space", then use something to grow the filesystem itself if it is not automatic. With btrfs subvolumes you do nothing. There are no constraints on the size of any of them, as long as there is free space on the big partition. Of course it has caveats. If there is corruption, all of them are affected, for instance. LVM also has caveats: it can break, and if it does you need to understand how to boot and rescue LVM. I don't, I don't want to spend time learning it (not interested), so I made the choice long ago to not use it :-) (nor do I use btrfs) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/15/2016 02:46 PM, Carlos E. R. wrote:
On 2016-03-15 18:37, jdd wrote:
Le 15/03/2016 18:04, Anton Aylward a écrit :
yes, and it's why I wonder is btrfs subvolumes are better or not. Subvolumes do not need at all fixed partitions, lvm allows easy changing.
as someone said, when fixing problem each level of difficulty is an obstacle. With lvm it's much more difficult to know how the disk is used (let only because the computer owner do not know this himself), devices names are pretty hard to remember, partitioning needs the correct driver version to be read (and chance is you don't have it), etc. If lwm go through several disks, I simply refuse to try.
That's the point.
With LVM you need to learn how to resize the spaces, and spend time doing it. Yes, you do not have fixed partitions, you can add space when you need it. Not always subtract space. But the admin has to do it. Posibly tell LVM to give more space to such "space", then use something to grow the filesystem itself if it is not automatic.
With btrfs subvolumes you do nothing. There are no constraints on the size of any of them, as long as there is free space on the big partition.
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries. Some people seem to consider this a good thing. While I can see why, I personally don't. I think that being unconstrained leads to poor operational discipline. I think that the "only computer knows" is a ridiculous argument. back when I began my career and there were few compilers and 'structured programming' was a thing of the future I had a manager who insisted we not only coded in assembler so we knew what was going on in the computer, but assembled everything because, as he said about link editors, you didn't really know what what was going on inside the computer. The same applies all the way down: even if you are programming in C or C++ you don't know the code that being produces (and it varies not only by target but also by compiler flags). You don't know where the virtual memory is mapping to physical memory. "Only the computer knows". Yes it will tell you if you ask, but that's for the realm of debugging. Most of us just trust it works and get on with life. The same as we do with all other technology that we don't have to learn the details of. you don't really know about metallurgy and chemistry and more to drive your car. In fact you mechanic probably doesn't either. If you don't think there should be constraints, then why don't you try driving just anywhere on the roadways, ignore signs and traffic lights? Constraints are what make things work well.
Of course it has caveats. If there is corruption, all of them are affected, for instance. LVM also has caveats: it can break, and if it does you need to understand how to boot and rescue LVM.
Yes, anything can break. The problems I've had with LVM I've always traced down to disk hardware and would have afflicted BtrFS as well. The days of simple bad sectors are past, the drive electronics has 'modules' that take care of remapping ... until it all gets overwhelming. There's a lot of "yes it used to be but we changed all that" in late model disk drives. The last time I had a catastrophic disk failure the manufacturer techs gave me a long and detailed explanation of how things now work and why the 'crash' I had was unrecoverable -- no matter what, and regardless of the file system. I've posted before about the use of the rescue disk and chroot to do repairs. it works for LVM as well. I've had file system wipe-outs with BtrFS that were unrecoverable, but no problem with ReiserFS has ever been unrecoverable. LVM also seems to be 'self repairing' in that its internal links and pointers lets the tools recover the structure correctly. *ANY* system needs learning and experimentation. John Andersen said
ts kind of like watching doctors play "hold my beer and watch this" while your kid is in the operating room on the heart-lung machine.
I think that is a spurious argument. Before he got to the operating room the doctor had to go though the years of pre-med education and training, and his education and doctor included a lot of experimentation in educational settings. Even when training in a hospital he was under supervision. its not like the software industry where fresh, inexperienced kids are set loose writing software that might be life-critical or business-critical. I admit that I have the fortunate situation of the junk in the Closet of Anxieties to play with. OK, much of it is way behind in terms of technology, no blazing fast graphics boards, no server boards with 2, 4 CPU slots and room for 128G of memory. Yes, a lot of SPF desktops. But I can still shove a new $50 2T drive on one of those and load up any one of the 32-bit operating systems and kick it around and abuse it. Yes, I'm fortunate.
I don't, I don't want to spend time learning it (not interested), so I made the choice long ago to not use it :-)
I made the decision not to learn about Windows :-0
(nor do I use btrfs)
I have been. I don't think I will be doing so for much longer. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 16, 2016 at 3:55 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries.
There are, on subvolume granularity.
Some people seem to consider this a good thing. While I can see why, I personally don't. I think that being unconstrained leads to poor operational discipline.
"No partitions" does not automatically imply "unconstrained". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/16/2016 09:04 AM, Andrei Borzenkov wrote:
On Wed, Mar 16, 2016 at 3:55 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries.
There are, on subvolume granularity.
Could you explain that and illustrate it please. Linda gave a wonderful and detailed example of using XFS, setting the 'granularity' there to make the most use of the partition and suited to a particular and specific type of file/application. Perhaps you could do the same with a subvolume, and them again with a another subvolume in a quite different manner.
Some people seem to consider this a good thing. While I can see why, I personally don't. I think that being unconstrained leads to poor operational discipline.
"No partitions" does not automatically imply "unconstrained".
The assertion made elsewhere that this is all one file system so that a subvolume is allocated space from the general 'pool' as files are created there is something that I take to be 'unconstrained'. If there is a way to limit the number of files in a subvolume (aka the number of inodes or inode/data ratio), or the amount of space those files can take up before a limit is forcible imposed, I would like an explanation of 'how'. Or perhaps we have a different idea of what 'constrained' means? My point here is that even without using quotas (which is something few people seem to have a handle on) the other "popular" file systems, such as ReiserFS, Ext4 and XFS, all have the ability to manage allocation, limits and more in ways that can be very specifically and very suited to types of files and to applications. All have the ability to 'grow', some can 'shrink' as well, given that the disk partition is there. LVM makes the ability to add new blocks to a partition easy, even if that means adding another disk/spindle. All this is done using conventional and established tools. And those file system report well with 'df' :-) Yes, specific users might not be familiar with some of those. Before Linda prompted me, I knew nothing of XFS. having a LVM system made it easy to experiment with XFS and see how it managed my videos compared to the ReiserFS I'd been using before. I'm now a 'convert"; thank you, Linda. I was willing to learn. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 16, 2016 at 5:20 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/16/2016 09:04 AM, Andrei Borzenkov wrote:
On Wed, Mar 16, 2016 at 3:55 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries.
There are, on subvolume granularity.
Could you explain that and illustrate it please.
It is illustrated by default openSUSE install and explained many times in this thread.
Some people seem to consider this a good thing. While I can see why, I personally don't. I think that being unconstrained leads to poor operational discipline.
"No partitions" does not automatically imply "unconstrained".
The assertion made elsewhere that this is all one file system so that a subvolume is allocated space from the general 'pool' as files are created there is something that I take to be 'unconstrained'.
If there is a way to limit the number of files in a subvolume (aka the
btrfs does not limit number of created files by design.
number of inodes or inode/data ratio), or the amount of space those files can take up before a limit is forcible imposed, I would like an explanation of 'how'.
I already answered it in this very thread. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/17/2016 04:16 AM, Andrei Borzenkov wrote:
On Wed, Mar 16, 2016 at 5:20 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/16/2016 09:04 AM, Andrei Borzenkov wrote:
On Wed, Mar 16, 2016 at 3:55 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
> > That's the whole point: with BtrFS there is *no* partitioning, its all > one file system. There are no boundaries.
There are, on subvolume granularity.
Could you explain that and illustrate it please.
It is illustrated by default openSUSE install and explained many times in this thread.
Perhaps we mean different things by 'granularity". When I mkfs a file system I can set the block size. I can set other things depending on the file system Linda did a very good illustration of this for XFS, how the block size and make best use of the partition, waste the least amount of space. Different types of file can profit from different block sizes or extents. I thin Linda made this point talking of how videos are stored differently from the kind of files you'll find in {/usr,}/bin and {/usr,}/lib. But when you mkfs a BtrFS its homogeneous. You've made the point, I've made the point,, others have made the point, that the files under a subvolume are all made up of blocks from the same "pool", that is the same - as I use the term - 'granularity'. Perhaps its more than a difference in use of terms, but if so I need a better explanation of how to set up subvolumes. There's a second point here. Altering block sizes at mkfs is a "bleedin' obvious" technique we've had for years, and its there in the YAST style mkfs as well. I'm an experienced BtrFS user, as I've mentioned, I've played with it since it came out on 13.1; I've tried it on file systems for music, photos and videos as well as the RootFS. I've tried it with subvolumes, tweaked subvolumes and without. There's a lot that can be tweaked with BtrFS, much more than other file systems https://btrfs.wiki.kernel.org/index.php/Mount_options Perhaps this is all overwhelming for anyone less than a dedicated sysadmin, dedicated not just in the role but in the willingness to experiment with 'all that" and learn the applicability and benefits. I don't claim to have explored the *all*, but I do, as I've said, tried them against XFS, ReisersFS, Nil2FS. I kinda like XFS ... Thank you Linda. Originally I liked BtrFS, I saw it as whet we might have instead of Reiser4; a couple of years on I'm disappointed. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-17 14:38, Anton Aylward wrote:
Originally I liked BtrFS, I saw it as whet we might have instead of Reiser4; a couple of years on I'm disappointed.
If you do a test to see if btrfs will handle files that reiserfs would handle, you probably will crash the filesystem (beyond repair) and the kernel. Try to create some million files in the same directory (the number depends on the size of the partition). When I did, some time ago, the kernel crashed, and the filesystem corrupted. It was impossible to repair, it needed a format. And before crashing it was going very slow. Reiserfs has no problem with that load. ext4 will simply refuse at some point, but no crash. XFS I don't remember. I think it filled up, but much later than ext4. A million files in one dir is a strange load, yes, but I wanted to test if btrfs would be comparable to reiserfs, and it is not. A mail server using maildir, or an nntp server, impose that kind of load. (there is an unsolved bugzilla, IIRC). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 17/03/2016 14:47, Carlos E. R. a écrit :
Try to create some million files in the same directory (the number
http://www.linux-mag.com/id/7876/2/ jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-17 14:54, jdd wrote:
Le 17/03/2016 14:47, Carlos E. R. a écrit :
Try to create some million files in the same directory (the number
No testing of reiserfs. :-} «He used 1,000 directories with 1,000 file each» Pooh. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-03-17 14:13, Carlos E. R. wrote:
On 2016-03-17 14:54, jdd wrote:
Le 17/03/2016 14:47, Carlos E. R. a écrit :
Try to create some million files in the same directory (the number
No testing of reiserfs. :-}
«He used 1,000 directories with 1,000 file each»
Pooh.
I still like reiserfs. XFS also works but I probably haven't spent enough time tweaking it, so I view it as a bit of a space hog. The admins here prefer ZFS and that seems to work but it absolutely must have SSD for the metadata otherwise it's a complete dog. JMHO, YMMV. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 17, 2016 at 7:47 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-03-17 14:38, Anton Aylward wrote:
Originally I liked BtrFS, I saw it as whet we might have instead of Reiser4; a couple of years on I'm disappointed.
If you do a test to see if btrfs will handle files that reiserfs would handle, you probably will crash the filesystem (beyond repair) and the kernel.
Try to create some million files in the same directory (the number depends on the size of the partition). When I did, some time ago, the kernel crashed, and the filesystem corrupted. It was impossible to repair, it needed a format. And before crashing it was going very slow.
Reiserfs has no problem with that load.
ext4 will simply refuse at some point, but no crash.
XFS I don't remember. I think it filled up, but much later than ext4.
A million files in one dir is a strange load, yes, but I wanted to test if btrfs would be comparable to reiserfs, and it is not. A mail server using maildir, or an nntp server, impose that kind of load.
(there is an unsolved bugzilla, IIRC).
# printf '%s ' {1..1000000} | xargs touch Less than one minute, no complaints. Takes longer to rm -rf. If I do it in a subvolume, 'btrfs sub del' returns immediately (the cleaner takes care of it later). One million files was passé 5 years ago when this presentation was done: http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf But even in 2010 btrfs was doing one million 50KiB file creation faster than ext4 or XFS (except on an SSD funny enough where it got beaten). But this ancient times. I'm not finding any one billion file tests. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-17 23:44, Chris Murphy wrote:
On Thu, Mar 17, 2016 at 7:47 AM, Carlos E. R.
(there is an unsolved bugzilla, IIRC).
# printf '%s ' {1..1000000} | xargs touch
Those are empty files. Have a look here: https://bugzilla.novell.com/show_bug.cgi?id=846807 What I did was: WHERE=/data/btrfs/test SAMPLE=$WHERE/sample ERROR=0 time for i in `seq -w 1 100`; do if [ $ERROR -ne 0 ]; then break fi echo $i for j in `seq -w 1 100`; do if [ $ERROR -ne 0 ]; then break fi for k in `seq -w 1 100`; do cp $SAMPLE $WHERE/TT-$i-$j-$k if [ $? -gt 0 ]; then echo "Copy error on TT-$i-$j-$k, abort" ERROR=1 break fi done done done -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Fri, Mar 18, 2016 at 3:21 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-03-17 23:44, Chris Murphy wrote:
On Thu, Mar 17, 2016 at 7:47 AM, Carlos E. R.
(there is an unsolved bugzilla, IIRC).
# printf '%s ' {1..1000000} | xargs touch
Those are empty files.
Why does it matter? In the bug, the test uses 100 bytes so they'd be written inline in the metadata node, no data extents would be written. So it's
Have a look here:
It's 18 month old, the question from the developer isn't answered. And hat bug doesn't refer to crashes, it's a bug about space not being freed. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 17, 2016 at 7:38 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
When I mkfs a file system I can set the block size. I can set other things depending on the file system Linda did a very good illustration of this for XFS, how the block size and make best use of the partition, waste the least amount of space. Different types of file can profit from different block sizes or extents. I thin Linda made this point talking of how videos are stored differently from the kind of files you'll find in {/usr,}/bin and {/usr,}/lib.
At the moment in Btrfs block size is fixed to kernel+arch page size, so on x86 that's a 4096 block and on PPC it's a 16KiB block. There is a different thing on Btrfs called a node (also leaf but now they're basically merged terms), and it's possible to set the nodesize at mkfs time. The old default was 4KiB, the current default for maybe two years now is 16KiB. This affects the effeciency of packing keys into the nodes, as well as ability to store inline data rather than using extents. So small files will actually have their data packed right next to their metadata in the node rather than being referenced elsewhere on the disk in a data extent. There are compression options. These can be per file or directory using an xattr if you want. There are a great many things Btrfs is poised to be able to do if you check out the features page, including per subvolume raid levels. And there's subvolume quotas which are immensely easier to figure out compared to XFS project quotas; but I have to say they're on their 3rd revision and it's not yet proven stable yet so it'll need more baking time. But it exists. Feel free to test it! A recent RFC patch was sent for per subvolume encryption, just in the last couple weeks. This is not about which file system is better it's which which one achieves your goals right now. It's a bit time consuming to migrate to a new file system but that's about it. So if Btrfs is not for you, you can use XFS now and maybe some other year Btrfs will have a feature you need that doesn't exist elsewhere.
But when you mkfs a BtrFS its homogeneous. You've made the point, I've made the point,, others have made the point, that the files under a subvolume are all made up of blocks from the same "pool", that is the same - as I use the term - 'granularity'.
Perhaps its more than a difference in use of terms, but if so I need a better explanation of how to set up subvolumes.
There's no actual need to use them. On the Btrfs list a number of users don't use subvolumes or snapshots at all. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/17/2016 04:16 AM, Andrei Borzenkov wrote:
If there is a way to limit the number of files in a subvolume (aka the btrfs does not limit number of created files by design.
This is one of the things that first attracted me to BtrFS. It is, it should be, a characteristic of a properly done B-tree file system. We saw that with ReiserFS. Carlos reports differently!
Try to create some million files in the same directory (the number depends on the size of the partition). When I did, some time ago, the kernel crashed, and the filesystem corrupted. It was impossible to repair, it needed a format. And before crashing it was going very slow.
The "use cases" of email and nntp are quite valid. Yes, Postfix ameliorates the situation by using hierarchies, but both are relevant in not only ISP settings but in corporate settings. Its not unusual for a corporation ot have many thousands of email addresses. I'd expect the main hubs at companies like IBM, HP and Oracle to be able to deal with millions, because they also have service accounts such as 'sales' and support' and more, as well as redirects and retires. Another use-case to consider is database. Some databases use on big file that contains everything and the DBMS deals with its internal structure, but there are many (MySQL/MariaDB) where these is one file per table and one file per index, and perhaps more. A corporate DB or a ISP that supports many users could have a million tables quite easily. In the spirit of BTDT, yes I've run an ISP and dealt with this. Big OUCH! And yes I've worked at corporations where there were BigData databases where the basic tables ran into the tens of thousands and the temporary tables for applications and more pushed that up by a factor of two to five. Bigger OUCH! Any file system where this a hard boundary between the inode space and the data space can potentially his this problem. huge disks may defer it, but we know full well that they eventually fill up. That's the nature of data! The issue of the boundary between inode space and data space has been around since the early days of UNIX, the V6/7 file system, the Berkeley Fast File System and even the ext4 file system all work that way. Read the man page for mkfs.ext4 and you'll see mention of /etc/mke2fs.conf. It is a way of specifying the inode/data trade off for different types of 'applications", The whole point of ReiserFS is that it avoids this problem. A proper B-tree FS should allocate resources dynamically; I don't understand why ext4FS doesn't. My hope for BtrFS as a replacement for ReiserFS in the absence of Reiser4 was that it would follow in this dynamic nature. Perhaps I should have bought another terabyte disk to devote to it and try the million-file test that Carlos reports. :-( -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-17 16:10, Anton Aylward wrote:
Perhaps I should have bought another terabyte disk to devote to it and try the million-file test that Carlos reports. :-(
Oh, you don't need that big a disk to run the test. Just use files of 0.1 or 1 KB. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 17/03/2016 17:30, Carlos E. R. a écrit :
On 2016-03-17 16:10, Anton Aylward wrote:
Perhaps I should have bought another terabyte disk to devote to it and try the million-file test that Carlos reports. :-(
Oh, you don't need that big a disk to run the test. Just use files of 0.1 or 1 KB.
size may be relevant if the file is stored in the inode or not jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-18 10:02, jdd wrote:
Le 17/03/2016 17:30, Carlos E. R. a écrit :
On 2016-03-17 16:10, Anton Aylward wrote:
Perhaps I should have bought another terabyte disk to devote to it and try the million-file test that Carlos reports. :-(
Oh, you don't need that big a disk to run the test. Just use files of 0.1 or 1 KB.
size may be relevant if the file is stored in the inode or not
Yes. I wanted to see if btrfs could do the same as reiserfs did with such small files. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-03-16 13:55, Anton Aylward wrote:
On 03/15/2016 02:46 PM, Carlos E. R. wrote:
With btrfs subvolumes you do nothing. There are no constraints on the size of any of them, as long as there is free space on the big partition.
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries. Some people seem to consider this a good thing. While I can see why, I personally don't. I think that being unconstrained leads to poor operational discipline.
You can create several partitions with btrfs as well, if that is your wish. Just it is not the default install at openSUSE.
Of course it has caveats. If there is corruption, all of them are affected, for instance. LVM also has caveats: it can break, and if it does you need to understand how to boot and rescue LVM.
Yes, anything can break. The problems I've had with LVM I've always traced down to disk hardware and would have afflicted BtrFS as well.
I don't say it wouldn't. I just say that I have seen corruptions, in which having LVM was an issue because the person affected and the helpers, none knew how to handle it. I saw the post for help. Me, I have seen corruptions on all types of filesystems, some worse than others. Few or none, AFAIR, caused by hardware. I don't count a power failure (intentional or not) as "hardware failure". Or a kernel/system crash/lock. I have seen disk failures, of the sort of "bad sectors, of course, in which case there is also typically corruption that can not be cleared. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/16/2016 09:16 AM, Carlos E. R. wrote:
You can create several partitions with btrfs as well, if that is your wish. Just it is not the default install at openSUSE.
That sort of misses the point of using the "pool" of the single big BtrFS partition. All you are saying here is that I was right to have partitions rather than the "all one big pool" of the default BtrFS so as to manage issues like boundaries and constraints. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 16/03/2016 15:22, Anton Aylward a écrit :
All you are saying here is that I was right to have partitions rather than the "all one big pool" of the default BtrFS so as to manage issues like boundaries and constraints.
it's only your choice and you can keep it if you wish. We don't have to challenge your reason to use this jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-16 12:55, Anton Aylward wrote:
when I began my career and there were few compilers and 'structured programming' was a thing of the future I had a manager who insisted we not only coded in assembler so we knew what was going on in the computer
When I began my career, we programmed in an assembly language that had no opcodes. We coded the operations directly in octal - 070 was a subroutine call IIRC. The idea was that when it came time to read the dump after a crash, we would already be very familiar with the octal. Dumps were on fanfold paper and we had a nice long office floor to spread them out. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 16/03/2016 14:57, Dave Howorth a écrit :
When I began my career, we programmed in an assembly language that had no opcodes. We coded the operations directly in octal - 070 was a subroutine call IIRC. The idea was that when it came time to read the dump after a crash, we would already be very familiar with the octal. Dumps were on fanfold paper and we had a nice long office floor to spread them out.
yes, me in Hex (0 to F). This allowed me to crack protections with the "debug" utility (DOS time)... this don't make us better :-( I also know how to build cars, but I'm not a better driver. if people say subvolumes are good, I try to understand why, but in the mean time I use them :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/16/2016 10:06 AM, jdd wrote:
I also know how to build cars, but I'm not a better driver.
I build my first computer and also wrote a lot of my own software. It definitely helped me be a better computer tech, when I maitained mini computers. I work in the telecommunications industry and often find myself working with people who have no idea what's out in the field or how systems worked in the past. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/16/2016 10:16 AM, James Knott wrote:
On 03/16/2016 10:06 AM, jdd wrote:
I also know how to build cars, but I'm not a better driver.
I build my first computer and also wrote a lot of my own software. It definitely helped me be a better computer tech, when I maitained mini computers. I work in the telecommunications industry and often find myself working with people who have no idea what's out in the field or how systems worked in the past.
+1 to all that, and yes, knowing how my car is built and works makes me a better driver, at the very least because I know its limits and its capabilities and don't try to make it do things that its not suited for or capable of. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/16/2016 09:57 AM, Dave Howorth wrote:
When I began my career, we programmed in an assembly language that had no opcodes. We coded the operations directly in octal - 070 was a subroutine call IIRC. The idea was that when it came time to read the dump after a crash, we would already be very familiar with the octal. Dumps were on fanfold paper and we had a nice long office floor to spread them out.
Are you sure there weren't op codes? Or perhaps you just weren't aware of them? I also used to work in octal on my Imsai 8080, but I still knew most of the op codes. I also worked in octal on some Data General mini computers. I also worked in microcode on them. I also worked a lot with paper tape and often had piles of it on the floor. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/16/2016 09:57 AM, Dave Howorth wrote:
On 2016-03-16 12:55, Anton Aylward wrote:
when I began my career and there were few compilers and 'structured programming' was a thing of the future I had a manager who insisted we not only coded in assembler so we knew what was going on in the computer
When I began my career, we programmed in an assembly language that had no opcodes. We coded the operations directly in octal - 070 was a subroutine call IIRC. The idea was that when it came time to read the dump after a crash, we would already be very familiar with the octal. Dumps were on fanfold paper and we had a nice long office floor to spread them out.
Cheers, Dave
Ah yes, "Those were the days, my fiend, we thought they'd never end .." I recall hearing Pontardawe-born Mary Hopkins singing that at an Eisteddfod in Wales back in the late 1960s. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 16, 2016 at 6:55 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/15/2016 02:46 PM, Carlos E. R. wrote:
With btrfs subvolumes you do nothing. There are no constraints on the size of any of them, as long as there is free space on the big partition.
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries.
Sorta mostly true but there is a distinction with subvolumes. They are a different file system tree, and in that sense is characteristic of a separate volume. For example you can have duplicate inodes on Btrfs. A particular inode number will appear only one time in a subvolume, but it can (and does) appear multiple times on a file system. And because of this you can't make hard links across subvolume boundaries, just like you can't hard link between two XFS volumes; and you can't do --reflink copies (presently) across subvolumes unless you use a fully qualified path from the top level (ID 5) subvolume. So there are some boundaries, they're just not identical to the boundaries we're used to. Subvolumes have other advantages also including send/receive: incremental send/receive produces a received subvolume that represents the entire current state of the sent subvolume (all files) even though it was an incremental send - due to shared extents.
If you don't think there should be constraints, then why don't you try driving just anywhere on the roadways, ignore signs and traffic lights? Constraints are what make things work well.
Blanket arguments are fun, because they're easy to turn around. OS X is very constrained, and even more constrained is iOS. Do they work well? In many ways yes, in other ways not.
Of course it has caveats. If there is corruption, all of them are affected, for instance. LVM also has caveats: it can break, and if it does you need to understand how to boot and rescue LVM.
Yes, anything can break. The problems I've had with LVM I've always traced down to disk hardware and would have afflicted BtrFS as well. The days of simple bad sectors are past, the drive electronics has 'modules' that take care of remapping ... until it all gets overwhelming.
Drives, especially flash, can and do return what it thinks is completely valid data, not a bad sector, but is actually not correct. And of all the Linux fs's, only Btrfs will prevent corrupt data from getting to user space (or actually even earlier, it's stopped in kernel code.) The exact path to the affected file is listed in kernel messages. LVM doesn't do this. There are all sorts of reasons how this is possible, torn writes, redirected writes, and so on, nothing else will see this. XFS v5 now has metadata checksumming, so it's improved, but data is not checksummed.
There's a lot of "yes it used to be but we changed all that" in late model disk drives. The last time I had a catastrophic disk failure the manufacturer techs gave me a long and detailed explanation of how things now work and why the 'crash' I had was unrecoverable -- no matter what, and regardless of the file system.
Btrfs doesn't work miracles. It's not going to recover data the drive itself considers corrupt. The thing Btrfs does is know when corruption has happened and the drive doesn't know it. It can happen outside of the drive, in cable connectors, or the controller.
I've posted before about the use of the rescue disk and chroot to do repairs. it works for LVM as well. I've had file system wipe-outs with BtrFS that were unrecoverable, but no problem with ReiserFS has ever been unrecoverable. LVM also seems to be 'self repairing' in that its internal links and pointers lets the tools recover the structure correctly.
Conventional linear LVM is like partitioning. It works by deduction, there really aren't any pointers until you start using snapshots and then things can get tricky and slow in a big hurry. The new LVM thin provisioning stuff is even more tricky, where there are lots of pointers and separate metadata pools, and separate repair tools that I would call distinctly non-obvious and non-trivial to use and works in progress. I've intentionally blown up thin provisioning volumes numerous times in ways I've never been able to do with Btrfs short of overwriting superblocks and wholesale sabotage. So I would not say LVM is bullet proof or easy to manage in comparison to Btrfs. However what makes a huge difference is familiarity. You'll naturally favor that with which you are familar. I see LVM as emacs, there's just too much going on and as yet it still doesn't have all the raid features found in mdadm. Nevertheless, LVM is badass, I just prefer to use Btrfs 95% of the time and use LVM mainly because it makes certain kinds of tests easier than qcow2 or loop mounted image files. We're fortunate to have many choices. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 10:20 AM, jdd wrote:
I never wanted to use lvm, because it makes fixing problems difficult and much of my time is spent fixing not working machines, why should I have subvolumes? I have no database on my desktop (none that have meaning), not even on my server
You've conjoined two issues in that sentence. Why do you think that using LVM makes fixing problems difficult? There are problems I have with many machines, recall I'm using 'discards' from the 'Closet of Anxieties', and regular readers will recall that I enjoy (for various values of 'enjoy') working with old equipment and stuff people think is not worth using any more. I use LVM specifically because I want to AVOID a whole set of problems! Yes you can put BtrFS and its subvolumes on a LV under LVM. That might be the source of your problems. Not fully understanding LVM though not using it enough might account for other difficulties. I've been using BtrFS since 13.1 was released. I've done a lot with it, played around with installing it for root and non root partitions. I've used subvolumes, and despite using them I still don't see how they are superior to mounting a file system instead. I've converted back and forth between BtrFS, XFS and ReiserFS. On the whole I feel more comfortable with ReiserFS and Ext4.
I have no database on my desktop (none that have meaning), not even on my server
Oh, really? You don't use, for example, Thunderbird or Firefox or Postfix or Dovecot by any chance? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 09:38 AM, Anton Aylward wrote:
On 03/15/2016 10:20 AM, jdd wrote:
I never wanted to use lvm, because it makes fixing problems difficult and much of my time is spent fixing not working machines, why should I have subvolumes? I have no database on my desktop (none that have meaning), not even on my server You've conjoined two issues in that sentence.
Why do you think that using LVM makes fixing problems difficult? There are problems I have with many machines, recall I'm using 'discards' from the 'Closet of Anxieties', and regular readers will recall that I enjoy (for various values of 'enjoy') working with old equipment and stuff people think is not worth using any more. I use LVM specifically because I want to AVOID a whole set of problems!
Yes you can put BtrFS and its subvolumes on a LV under LVM. That might be the source of your problems.
Not fully understanding LVM though not using it enough might account for other difficulties.
I've been using BtrFS since 13.1 was released. I've done a lot with it, played around with installing it for root and non root partitions. I've used subvolumes, and despite using them I still don't see how they are superior to mounting a file system instead. I've converted back and forth between BtrFS, XFS and ReiserFS. On the whole I feel more comfortable with ReiserFS and Ext4.
I have no database on my desktop (none that have meaning), not even on my server Oh, really? You don't use, for example, Thunderbird or Firefox or Postfix or Dovecot by any chance?
On all the info I've read, LVM is another layer that can obsfucate other problems, I have to agree with jdd here. I'd opine you'd have a more reliable system with btrfs and subvols, rather than making some complicated mess with LVM with partitions all over the place. KEEP IT SIMPLE "KISS" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 12:41 PM, sdm wrote:
On all the info I've read, LVM is another layer that can obsfucate other problems, I have to agree with jdd here. I'd opine you'd have a more reliable system with btrfs and subvols, rather than making some complicated mess with LVM with partitions all over the place. KEEP IT SIMPLE "KISS"
I'm sure that someone can make a mess with anything they choose, but that's not the point. LVM is not just a partition tool; it is there to manage spindles, deal with issue like striping and mirroring. If I just wanted to partition I'd use Parted. As for KISS, part of that gets back to the "do just one thing". LVM manages the multiple disks, much like mdadm manages multiple disks for RAID. Putting ext4 or ReiserFS on a LV is more KISS than using BtrFS because, as I've previously mentioned, BtrFS tries to do everything all in one. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/03/2016 17:38, Anton Aylward a écrit :
On 03/15/2016 10:20 AM, jdd wrote:
Yes you can put BtrFS and its subvolumes on a LV under LVM. That might be the source of your problems.
certainly not. Sorry, Im' not as fluent in English as I would like. What I would say is: I do not use lvm, why should I use subvolumes?
Not fully understanding LVM though not using it enough might account for other difficulties.
for sure. But the less I have to know the better when I'm on a hurry because somebody ask for help...
comfortable with ReiserFS and Ext4.
I liked a lot reiserfs and now use ext4 as often as I can, I use btrfs on my main computer because it was the default install and I can't convert, and on new demos to learn it, but it's not something that come easily :-(
I have no database on my desktop (none that have meaning), not even on my server
Oh, really? You don't use, for example, Thunderbird or Firefox or Postfix or Dovecot by any chance?
yes, I do, but do not have any speed constrain. My server is oversized and my desktop have no database I really rely on. I don't trust databases not managed by somebody that really know how. jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-03-15 13:38, Anton Aylward wrote:
In particular you don't address why mounted file systems should not be used instead of subvolumes.
Because nobody said that. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlboLT4ACgkQja8UbcUWM1yABAEAjCmf7yO0p8yACNBeJ0M3Gdtq tyars6p9s8UqgTuRVj0BAIlzcL5m40MV6YvlD2gdRz/7WwF/R0FpZZ42iJUHFwfJ =k+ri -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 05:38 AM, Anton Aylward wrote:
No. I'm sure some on the list found you TL;DR interesting but it didn't tell me anything I didn't already know this time last year and completely failed to address any of my reasons why I'm, after a long stint and trying to promote BtrFS, finally giving up on it.
I've been using Btrfs w/o ever even 1 issue on servers and desktops, including ones that have experienced the power being cut more than once. Never one problem, ever. Hardware problems such as 3 cent motherboard "China RAID/Fake RAID" controllers could be to blame in certain circumstances which in those cases aren't the actual filesystem. Point is I suspect a lot of people posting for problems and blaming openSUSE or the FS (which in many cases it also is the fault of buggy software) is actually because their hardware is complete shit, old, whatever...E-waste. Not saying that that's your hardware or your hardware is at fault, but I wanted to remind everyone that hardware plays a BIG role in the bits running on all those chips, some of which get extremely hot and don't last forever. I think Btrfs is actually is production ready, and in all my time never had any issues with NTFS, EXT4, XFS, and Btrfs. The power has been cut on all those systems which had one or more of the aforementioned FS's running and never 1 problem. Now, not all of them were in RAID configs (such as XFS), but in single drive configs XFS has never had 1 issue. As for the op, the statement is so vague and I still haven't read this entire thread yet, it so far seems to be such a vague question "I did this, it didn't like it, what can I do? If we had specifics, the solution would come about in half the amount of nonesense back and forth emails sdm -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 11:58 AM, sdm wrote:
On 03/15/2016 05:38 AM, Anton Aylward wrote:
No. I'm sure some on the list found you TL;DR interesting but it didn't tell me anything I didn't already know this time last year and completely failed to address any of my reasons why I'm, after a long stint and trying to promote BtrFS, finally giving up on it.
I've been using Btrfs w/o ever even 1 issue on servers and desktops,
Yes, I too have been using it for many a year, certainly since 13.1 came out.
including ones that have experienced the power being cut more than once. Never one problem, ever.
Good for you. I can say the same about the ReiserFS I run on top of LVM. I've heard people say the same about other journalled file systems. So can we factor that out of the discussion as it isn't a specific benefit of BtrFS.
Hardware problems such as 3 cent motherboard "China RAID/Fake RAID" controllers could be to blame in certain circumstances which in those cases aren't the actual filesystem. Point is I suspect a lot of people posting for problems and blaming openSUSE or the FS (which in many cases it also is the fault of buggy software) is actually because their hardware is complete shit, old, whatever...E-waste.
I've commented many times on the fact that I do make use of discarded, obsolete or marginal hardware and enjoy the challenge of getting it to work. I've got maybe 100kg of 'junk' in and around my bench in the basement. I may not be the most adroit person with a soldering iron by I've repaired a number of 'Bad Cap' items, no least of all this wide-screen I'm using at the moment. Heck, I've even managed to get el-cheapos "AMD" memory chips to work on Intel mobos! I am quite capable of drawing the distinction between a hardware failure (or shortcoming) and a software problem, thank you very much. having been doing it for about 50 years might have something to do with that. I'll grant you that not everybody has my experience in such areas, but then I don't have the experience that Carlos and Felix have in multi-book and and with newer "cooler" hardware. In fact many of the problems people are having with systems that are way beyond anything in my "Closet" leave me gaping and envious. Mind you, I'm not sure what I'd do with such hardware and if I had the money to spare for that bleeding edge stuff I could find better uses for it, -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 10:18 AM, Anton Aylward wrote:
On 03/15/2016 11:58 AM, sdm wrote:
On 03/15/2016 05:38 AM, Anton Aylward wrote:
No. I'm sure some on the list found you TL;DR interesting but it didn't tell me anything I didn't already know this time last year and completely failed to address any of my reasons why I'm, after a long stint and trying to promote BtrFS, finally giving up on it. I've been using Btrfs w/o ever even 1 issue on servers and desktops, Yes, I too have been using it for many a year, certainly since 13.1 came out.
including ones that have experienced the power being cut more than once. Never one problem, ever. Good for you. I can say the same about the ReiserFS I run on top of LVM. I've heard people say the same about other journalled file systems.
So can we factor that out of the discussion as it isn't a specific benefit of BtrFS.
Hardware problems such as 3 cent motherboard "China RAID/Fake RAID" controllers could be to blame in certain circumstances which in those cases aren't the actual filesystem. Point is I suspect a lot of people posting for problems and blaming openSUSE or the FS (which in many cases it also is the fault of buggy software) is actually because their hardware is complete shit, old, whatever...E-waste. I've commented many times on the fact that I do make use of discarded, obsolete or marginal hardware and enjoy the challenge of getting it to work. I've got maybe 100kg of 'junk' in and around my bench in the basement. I may not be the most adroit person with a soldering iron by I've repaired a number of 'Bad Cap' items, no least of all this wide-screen I'm using at the moment.
Heck, I've even managed to get el-cheapos "AMD" memory chips to work on Intel mobos!
I am quite capable of drawing the distinction between a hardware failure (or shortcoming) and a software problem, thank you very much. having been doing it for about 50 years might have something to do with that.
I'll grant you that not everybody has my experience in such areas, but then I don't have the experience that Carlos and Felix have in multi-book and and with newer "cooler" hardware. In fact many of the problems people are having with systems that are way beyond anything in my "Closet" leave me gaping and envious. Mind you, I'm not sure what I'd do with such hardware and if I had the money to spare for that bleeding edge stuff I could find better uses for it,
Not questioning your expertise & hardware, had no idea what hardware you are even for your daily driver, although I remember an email about "closet of anxieties". I do the same thing, pick up recycled parts and build systems and I know the hardware is good even if it's old...It was directed at, generally, other people who are having idiosyncratic problems with openSUSE and it actually turns out to be because their hardware is at fault. It's just something many "software people" don't always take into consideration. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/15/2016 01:35 PM, sdm wrote:
..It was directed at, generally, other people who are having idiosyncratic problems with openSUSE and it actually turns out to be because their hardware is at fault. It's just something many "software people" don't always take into consideration.
I'm sure there are such. I prefer not to presume that people can't learn unless that make it very clear that they are unwilling to learn. I have a suspicion that 'hardware hacking' such as we speak off has gone out of fashion. The 'maker' culture seems to have been handed over to, perhaps, the Chinese, and we in the west have been spoilt by having easy access to wave after wave of low cost innovation. Any of the corporate 'discards' I play with are, as many have pointed out, more powerful than the Apollo moonshot computers. The same goes for my early cell phone that barely ranks as a smartphone, from before Android was released. Contrariwise, almost everything these days has a computer in it, regardless. ten years ago that wasn't so; you could get stoves, fridges, even hearing aids that didn't have a processor in them. I'm sure the IoT will mean that pens and pencils coffee cups will have processors in them soon, and be more expensive for it! So now we really have function defined by software and people think of software first when something doesn't work. They don't actually need to be 'software' people. All that being said, when my software controlled microwave turns off after a couple of seconds I give it a slap on the side. There seems to be a loose connection on the fan. It all 'tamper proof', not like the microwaves when I was a kid that I could repair. *sigh* -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/03/2016 19:17, Anton Aylward a écrit :
be a loose connection on the fan. It all 'tamper proof', not like the microwaves when I was a kid that I could repair.
not speaking about cars... I own some old car or bicycle only to be able to get hands on mechanic you are rigth. on the same time, using always good old stuf and soft makes us lose some interesting new options. It's a reason why I always try a new distro. I had a very hard time learning grub legacy some years ago, and delayed as much as I could using grub2, to finally notice it uses nearly the same commands :-) new is sometime good - but not always :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-03-15 16:58, sdm wrote:
I've been using Btrfs w/o ever even 1 issue on servers and desktops, including ones that have experienced the power being cut more than once. Never one problem, ever. Hardware problems such as 3 cent motherboard "China RAID/Fake RAID" controllers could be to blame in certain circumstances which in those cases aren't the actual filesystem. Point is I suspect a lot of people posting for problems and blaming openSUSE or the FS (which in many cases it also is the fault of buggy software) is actually because their hardware is complete shit, old, whatever...E-waste.
I run a test on btrfs, some time ago, that would crash it hard, kernel failure. There is a bugzilla about it, and as far as I know, not closed yet. And it is a known software problem, not hardware. You may not have hit software problems on btrfs, but other people have. If you are interested in checking, try writing many thousands of small files on a single directory, see what happens when you reach the million figures. Some filesystems error out nicely, some accept those many files without a problem or slowness, and some first slow down, and later they crash badly. Yes, it is a test. There not many real world loads that do this, but mainly because this has always been a problem and applications bypass it by dividing the load on a bunch of directories instead of doing it in a single one. Other people may know about other instances of software problems on filesystems. I happen to know about this one :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-03-15 00:20, Anton Aylward wrote:
On 03/14/2016 06:06 PM, Carlos E. R. wrote:
Of course you can replace them with real partitions. If you don't, you should keep the subvolumes.
Please explain why one should keep the subvolumes?
Several reasons. Some are configured differently. No COW for databases, no snapshot revert on logs... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Mar 14, 2016 at 12:43 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-03-14 15:22, Anton Aylward wrote:
On 03/14/2016 09:42 AM, Carlos E. R. wrote:
So, yes, leave those spaces alone ;-)
I have come to think that this is a weak argument.
The fact is, if you are using btrfs, you need several subvolumes each tuned differently. As simple as that.
What, you do not like that lot of lines in df output? Well, that's df fault. It does not distinguish bind mounts either. We'd need new options to tell df to ignore certain stuff (like tmpfs). It has nothing to do with the installer, nor with discussing if btrfs is good or not. IF you use btrfs, you have to create those many subvolumes.
It's a design decision that resulted in the layout. The subvolumes are created to make it possible to snapshot a single path, while making nested subvolumes immune to snapshots. It's basically a way to carve out a rollback behavior that rolls back the right things and not the wrong things. It's not easy because the FHS is basically terrible in organization and the use case for paths is constantly changing. I mean, in 2016 it's rather annoying that desktop linux isn't as easy to separate out: the OS, the apps, system settings, user data. My phone makes backup and restore 8000% easier than the desktop. Granted, a big part of it is the non-privacy aspect of cloud services. But that could be mimicked with FOSS solutions, the main thing is to have the proper separation and desktop linux doesn't have that right now. It spews applications all over the place right along side OS included binaries. It's just awful. Next, if you look at the ostree project (including rpm-ostree), they have similar problems but deal with it differently. Instead of subvolumes as filesystem trees, they use directories and hardlinks, so it can work on Btrfs, XFS or ext4. But it also at the moment is more rigid in that /usr is read only. Rollbacks are limited by default to just one (two trees, current and previous). And how to install programs is completely different (container and in the future xdg-app based). So it's really different. But the way forward is it separates things better, and makes it easier to support application cross distros and distro versions. We'll see. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (17)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Chris Murphy -
Dave Howorth -
David T-G -
Felix Miata -
James Knott -
jdd -
John Andersen -
Per Jessen -
Ruben Safir -
Ruben Safir -
sdm -
Uzair Shamim -
Vojtěch Zeisek -
Yamaban