The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <>
To: Jon Steinhart <>
Cc: The Unix Heretics Society mailing list <>
Subject: Re: [TUHS] Is it time to resurrect the original dsw (delete with switches)?
Date: Mon, 30 Aug 2021 17:05:10 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Jon Steinhart wrote in
 |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.

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

  parent reply	other threads:[~2021-08-30 17:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-29 22:12 Jon Steinhart
2021-08-29 23:09 ` Henry Bent
2021-08-30  3:14   ` Theodore Ts'o
2021-08-30 13:55     ` Steffen Nurpmeso
2021-08-30  9:14   ` John Dow via TUHS
2021-08-29 23:57 ` Larry McVoy
2021-08-30  1:21   ` Rob Pike
2021-08-30  3:46   ` Theodore Ts'o
2021-08-30 23:04     ` Bakul Shah
2021-09-02 15:52       ` Jon Steinhart
2021-09-02 16:57         ` Theodore Ts'o
2021-08-30  3:36 ` Bakul Shah
2021-08-30 11:56   ` Theodore Ts'o
2021-08-30 22:35     ` Bakul Shah
2021-08-30 15:05 ` Steffen Nurpmeso [this message]
2021-08-31 13:18   ` Steffen Nurpmeso
2021-08-30 21:38 ` Larry McVoy
2021-08-30 13:06 Norman Wilson
2021-08-30 14:42 ` Theodore Ts'o
2021-08-30 18:08   ` Adam Thornton
2021-08-30 16:46 ` Arthur Krewat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).