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

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

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

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 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 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 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

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

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 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 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

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

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

Le 14/03/2016 22:52, Uzair Shamim a écrit :

alias test=$'df | awk -F" " \'!_[$1]++\''

it's exactly what I needed , 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

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 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 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

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 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 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 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 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

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

Le 15/03/2016 16:13, Andrei Borzenkov a écrit :

Отправлено с iPhone

...

15 марта 2016 г., в 17:20, jdd написал(а):

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

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 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 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 03/16/2016 09:04 AM, Andrei Borzenkov wrote:

On Wed, Mar 16, 2016 at 3:55 PM, Anton Aylward 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 03/17/2016 04:16 AM, Andrei Borzenkov wrote:

On Wed, Mar 16, 2016 at 5:20 PM, Anton Aylward wrote:

...

...

On 03/16/2016 09:04 AM, Andrei Borzenkov wrote:

...

...

On Wed, Mar 16, 2016 at 3:55 PM, Anton Aylward 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

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: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

http://www.linux-mag.com/id/7876/2/

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 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 Thu, Mar 17, 2016 at 7:38 AM, Anton Aylward 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 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)

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 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

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

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 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 Wed, Mar 16, 2016 at 6:55 AM, 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.

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 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

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

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 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

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 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)