On 26 February 2017 at 18:04, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Hello Carlos, I am quite astonished what a reaction has been triggered by my writing. To comment what Carlos has been saying: I usually have a partition setup with /boot, / and /home as separate partitions.
Because / does not change significantly there is IMHO no real need for it to be that large, 50 GByte - 100 GByte should be more than sufficient.
If that is inappropriate with btrfs - well, I'd say again, then this fs is not appropriate for the things a normal user would do. In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
"The music plays" in /home, what I'd make as big as possible. And, +1 for the comments of Carlos with regard to btrfsck - if using it breaks the file system, then it should nor be distributed neither installed.
A regular approach is to check a filesystem with XXXfsck, and it is the very responsibility of that tool to not destroy anything and to guide you through problems if problems are found.
from btrfsck (aka "btrfs check") --help "WARNING: the repair mode is considered dangerous" from man btrfs check "Warning Do not use --repair unless you are advised to by a developer, an experienced user or accept the fact that fsck cannot possibly fix all sorts of damage that could happen to a filesystem because of software and hardware bugs." from man e2fsck (aka fsck.ext2/3/4) " Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ``no''. Only experts who really know what they are doing should consider answering this question in any other way." from man xfs_repair " The filesystem to be checked and repaired must have been unmounted cleanly using normal system administration procedures (the umount(8) command or system shutdown), not as a result of a crash or system reset. If the filesystem has not been unmounted cleanly, mount it and unmount it cleanly before running xfs_repair" " xfs_repair does not do a thorough job on XFS extended attributes. The structure of the attribute fork will be consistent, but only the contents of attribute forks that will fit into an inode are checked. This limitation will be fixed in the future. " "The no-modify mode (-n option) is not completely accurate. It does not catch inconsistencies in the freespace and inode maps, particularly lost blocks or subtly corrupted maps (trees). The no-modify mode can generate repeated warnings about the same problems because it cannot fix the problems as they are encountered. If a filesystem fails to be repaired, a metadump image can be generated with xfs_metadump(8) and be sent to an XFS maintainer to be analysed and xfs_repair fixed and/or improved." The conclusion you can take from the above is that all fsck tools are somewhat unsafe, all should be taken with some care and btrfs is the only one which clearly documents this fact not only in it's man page, but also at runtime in the command. Which is the more responsible tool as a result? e2fsck? I think not.
At the end of the das I would like to rise the question again: "btrfs has new and interesting features". Well, for whom? Am I offered a car with 5 rather than 4 wheels now? Does this help me getting better from location A to location B?
I would expect that distribution maintainers are very very careful when it comes to changing the basic basic infrastructure of a system - and, in this case I see no good reason for this to be done. Something new is not neccessarily good, newness is no positive attribute as such, and when the only _siginificant_*) difference can be reduced to "because it is new", then there is no sense in the switch - IMHO, as always. And, something old in turn is not neccessarily bad simply because it is old.
The most reliable elements in a linux systems are the tools like "dd", "tar", "ls" and so on and so forth.
The answer to your question is so simple I'm surprised I have to explain it, but here goes. Consider the key benefits of openSUSE Tumbleweed and Leap Tumbleweed - a rolling distribution you can rely on Leap - an enterprise-based distribution including fully integrated with community packages Regarding Tumbleweed - despite all the magic we have in OBS and openQA, there is always the risk that a rolling update could break something, or at least change something in a way that a user is not expecting. In that case, you need a system to be able to magically revert anything so you can go back to a last known good, trusted state. ie. you need root filesystem snapshots ie. you need snapper and btrfs therefore, btrfs is the default root filesystem for Tumbleweed. Regarding Leap - enterprise linux are not rolling, but they are using their enterprise linux in environments where the shortest outages can cause millions of dollars of lost revenue. In that case, you need a system to be able to magically revert anything done by the sysadmin or by the software vendor to a last known good, trusted state. ie. you need root filesystem snapshots ie. you need snapper and btrfs therefore, btrfs is the default root filesystem for SUSE Linux Enterprise Leap is based on SUSE Linux Enterprise therefore btrfs is the default root filesystem for openSUSE Leap You may be neither a rolling user nor an enterprise one, but for years the openSUSE Project has had countless of its users lobbying for a regular release distribution with more stability like an enterprise distribution, a release schedule more like an enterprise distribution, and a feature set that at least matches an enterprise distribution. With Leap you get that, plus extra, which means adopting standard tooling and features which are now expected in enterprise settings. This might mean a little more education, study, and care is required. But we haven't rushed into this, it shouldn't be a surprise, btrfs has been around in openSUSE for years now, and the default for years also. You were given a fair opportunity to learn and get used to these new technologies in advance, you still have an opportunity to catch up, but requesting a reversion to something which is a key part of both of openSUSE's main distribution offerings is unlikely to get traction. Especially as you do not appear to be volunteering to do any of the work, just asking others to do it for you..why should our maintainers discard they work they've been doing just because it doesn't suit you? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org