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