[TUHS] Is it time to resurrect the original dsw (delete with switches)?

[Steffen Nurpmeso]

Jon Steinhart wrote in
 <202108292212.17TMCGow1448973 at darkstar.fourwinds.com>:
 |I recently upgraded my machines to fc34.  I just did a stock
 |uncomplicated installation using the defaults and it failed miserably.
 |
 |Fc34 uses btrfs as the default filesystem so I thought that I'd give it
 ...

 |Any of the rest of you have any experiences with btrfs?  I'm sure that it
 |works fine at large companies that can afford a team of disk babysitters.
 |What benefits does btrfs provide that other filesystem formats such as
 |ext4 and ZFS don't?  Is it just a continuation of the "we have to do
 |everything ourselves and under no circumstances use anything that came
 |from the BSD world" mentality?

From a small man perspective i can say i use btrfs.  I have seen
more problems with filesystems in these 29 months than in the ~36
years (well, 22 if you only count Unix, mostly FreeBSD) before.

I have learned that i have to chattr +C my vm/ directory in order
to avoid filesystem errors which can only be solved by deleting
the corrupted files (which were not easy to find out,
inspect-internal inode-resolve could have helped a bit better, but
.. why?).  I have seen (factual) snapshot receive errors that were
not indicated by the tool's exit status.  With dangling files
laying around.   I have seen +C attributes missing on the target
filesystem from played in snapshots.  I have found it impossible
to mount external devices because "BTRFS warning (device
<unknown>): duplicate device /dev/sdc2 devid 1 generation 3977"
even though the former umount was successful (i must admit i had
used lazytime mount option there, be sure not to do that for
BTRFS).  I know where you coming from, i tried it all without
success.  With all the little tools that do not do what you want.

I found it quite ridiculous that i had to shrink-resize my
filesystem in an iteration because the "minimum possible" size was
adjusted each and every time, until i finally was where the actual
filesystem usage indicated you would end up with from the
beginning.  (defrag did not prevent this.)

On the other hand i am still here, now on Luks2, now with xxhash
checksums and data and meta DUP (instead of RAID 1, i thought).
Same data, just moved over onto.

I think i would try out ZFS if it would be in-kernel.  The FreeBSD
Handbook is possibly the best manual you can have for that.  But
i mean the ZFS code is much, much larger than BTRFS, BTRFS serves
me really, really good for what i want and need, and i am sailing
Linux stable/latest (4.19, now 5.10) here, on a free and small
Linux distribution without engineering power aka supervision, that
sails somewhat the edge of what all the many involved projects
produce, with problems all over the place, sometimes more,
sometimes less, some all the time.  That is nothing new, you have
to live with some deficiencies in the free software world; i just
find it sometimes hard to believe that this is still true for
Linux with the many many billions of Dollars that went in, and the
tens of thousands of people working on it.

I really hate that all the Linux kernel guys seem to look forward
only, mostly, you have to go and try out the newest thing, maybe
there all is good.  Of course .. i can understand this (a bit).
That is the good thing of using such an engineering-power
distribution, you likely get backports and have a large user base
with feedback.

 |In my limited experience btrfs is a BiTteR FileSystem to swallow.

Well often people say you need to know what you are doing.  That
is hard without proper documentation, and the www is a toilet.
And noone writes HOWTOs any more.  But, for example, if i do not
use an undocumented kernel parameter (rtw88_pci.disable_aspm=1),
and use wifi and bluetooth (audio) in conjunction, then i have to
boot into the Windows startup screen in order to properly
reinitialize my wifi/bluetooth chip.  Or else you are dead.  And
that even though it seems the Linux driver comes from the Chip
creator itself.  So i think a "chattr +C" here and there, it can
be directory-wide, it could be a mount or creation option, isn't
that bad.  Also it is just me having had a go (or julia or nim; or
perl) on using _one_ filesystem with several subvolumes for
anything; if i would have used my (well, security context only)
old-style way of doing things and used several hard partitions
with individual filesystems, i would have used +C from the
beginning for that one.  Especially if i would have read it in the
manual page.

I do believe todays' journalled, checksummed, snapshot'able
copy-on-write filesystems are complex beasts.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)