On Thu, Mar 24, 2016 at 12:37 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/24/2016 02:07 PM, Chris Murphy wrote:
In my first post on this thread I didn't suggest a Btrfs /home for example. My two recommendations included retaining XFS for /home.
Every analysis I've done of the advantages of BtrFS for myself lead me to think that when its finished, when its done all the deduplication bits and more, it will be of more use for /home than for the RootFS.
It depends on the use case. On ARM it's common to depend on SD cards, and Btrfs will never pass corrupt data to user space. Corrupt user data is a kind of data loss, not good. But corrupt system files can lead to crashes and more corruption of both system files and user data. So, really not good.
But end users are another matter. End users make mistakes. End users might delete or overwrite a file and want to get back the previous version. Snappshoting of the user space is a major issue. That's why we have http://snapper.io/manpages/pam_snapper.html
Yes but this can be mitigated with statelessness also, similar to a mobile device, but with better and more plain language granularity. Instead of rolling back by date, just have one roll back state for different domains: system itself including non-app updates; apps; system settings; user settings; user data. The FHS does not help us with this separation, it's actually a hindrance.
I have a similar argument for "shared services", ISPs, that it is better to put user files on a SSD that the core binaries of {/usr/,}/bin and {/usr,}/lib since the shared binaries are going to be loaded once then resident but the real 'churn"' is with the users' application data and they want that loaded fast.
Sure or just use something like lvmcache or bcache and let the technology figure out what files are hot vs warm vs cold, and the optimization is dynamic rather than fixed. Sysadmins want to be able to template this stuff so they can get a bunch of servers or VM's up and running without having to do so much customization while still getting optimization. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org