All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Nix <nix@esperi.org.uk>
Cc: George Rapp <george.rapp@gmail.com>,
	Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Recommended filesystem for RAID 6
Date: Wed, 12 Aug 2020 19:41:41 +0500	[thread overview]
Message-ID: <20200812194141.0b86d7ee@natsu> (raw)
In-Reply-To: <87sgcsar0a.fsf@esperi.org.uk>

On Wed, 12 Aug 2020 15:16:37 +0100
Nix <nix@esperi.org.uk> wrote:

> On 11 Aug 2020, Roman Mamedov stated:
> > For the FS considerations, the dealbreaker of XFS for me is its inability to
> > be shrunk. The ivory tower people do not think that is important enough, but
> > for me that limits the FS applicability severely. Also it loved truncating
> > currently-open files to zero bytes on power loss (dunno if that's been
> > improved).
> 
> I've been using XFS for more than ten years now and have never seen this
> allegedly frequent behaviour at all. It certainly seems to be less
> common than, say, fs damage due to the (unjournalled) RAID write hole.
> 
> I suspect you're talking about this:
> <https://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F>,
> whicih was fixed in *2007*.

No, it was not nulls inside files, but files becoming zero bytes in size.
Like reported here https://bugzilla.redhat.com/show_bug.cgi?id=845233
Or maybe https://access.redhat.com/solutions/272673 too (don't have an account)
Maybe also fixed since 2012. If so, good for you.

> Shrinking xfs is relatively irrelevant these days: if you want to be
> able to shrink, use thin provisioning and run fstrim periodically. The
> space used by the fs will then shrink whenever fstrim is run, with no
> need to mess about with filesystem resizing.

It also means you can't practically remove drives from that 16-drive RAID6 if
you go with XFS. Cannot shrink the filesystem, cannot reshape to fewer disks.
Cannot switch to a different disk enclosure with fewer slots.
Would you suggest to patch that up with running an array-wide Thin volume as
well? Will not work, as the LVM thin backing volume *itself* cannot be shrunk
either. And even in more suitable conditions, thin has its own overheads and
added complexity.

Well, if we are to mention something positive about XFS, it's another major
Linux FS other than Btrfs (which is not everyone's cup of tea for its own
reasons), that now got support for reflink copies (cp --reflink). Backing up
file-based VMs can be done online and atomically now, like with LVM. And in
general, it's the next-best thing to Btrfs snapshots, but in a mature and
all-around high-performing FS.

-- 
With respect,
Roman

  reply	other threads:[~2020-08-12 14:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11  4:42 Recommended filesystem for RAID 6 George Rapp
2020-08-11 15:06 ` Roy Sigurd Karlsbakk
2020-08-11 19:19   ` Michael Fritscher
2020-08-11 19:45     ` Wols Lists
2020-08-22  1:31       ` David C. Rankin
2020-08-22  7:25         ` Peter Grandi
2020-08-22  9:38           ` Wols Lists
2020-08-22 19:21             ` Chris Murphy
2020-08-22 19:04           ` Chris Murphy
2020-08-22 18:50       ` Chris Murphy
2020-08-22 19:54         ` Kai Stian Olstad
2020-08-22 23:50         ` antlists
2020-08-12 14:07     ` Nix
2020-08-11 15:22 ` antlists
2020-08-11 16:23 ` Roman Mamedov
2020-08-11 18:57   ` Reindl Harald
2020-08-11 19:33     ` Roman Mamedov
2020-08-11 19:49       ` Rudy Zijlstra
2020-08-11 20:13         ` Roman Mamedov
2020-08-11 20:17           ` Reindl Harald
2020-08-11 20:12       ` Reindl Harald
2020-08-11 22:14   ` Roy Sigurd Karlsbakk
2020-08-12 14:16   ` Nix
2020-08-12 14:41     ` Roman Mamedov [this message]
2020-08-12 20:44 ` Peter Grandi

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20200812194141.0b86d7ee@natsu \
    --to=rm@romanrm.net \
    --cc=george.rapp@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=nix@esperi.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.