unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
From: Eric Wong <e@yhbt.net>
To: meta@public-inbox.org
Subject: what storage system(s) are you using?
Date: Wed, 5 Aug 2020 03:11:27 +0000	[thread overview]
Message-ID: <20200805031127.GA11917@dcvr> (raw)

I've been mostly using ext4 on SSDs since I started public-inbox
and it works well.

1.6.0 will have some changes to make things less slow on
rotational HDDs (and even faster on SSD).  It's still slow, just
a bit less slow than before.  Testing things on giant inboxes is
like watching grass grow.  Small inboxes that can fit into the
page cache aren't too bad...

I'm also evaluating btrfs since its raid1 is handy when I've got
a bunch of old mismatched HDDs for backups.  btrfs may become
the default FS for Fedora (and maybe other distros will follow),
so I anticipate we'll see more btrfs adoption as time goes on.

Out-of-the-box, btrfs is not remotely suited for random write
patterns from Xapian and SQLite.  However it gives some extra
piece-of-mind with checksumming and compresssion of git refs.
Since we don't care much about data integrity of Xapian or
SQLite data, 1.6.0 will set the nodatacow attribute on those
files/directories:

  https://public-inbox.org/meta/20200728222158.17457-1-e@yhbt.net/

With the default CoW, even a TRIM-ed SSD was abysmal at indexing
LKML.

The space_cache=v2 mount option seems to help significantly with
large, multi-TB FSes (still testing...).  This will be noted in a
public-inbox-tuning(7) manpage...

I haven't done much with XFS outside of a VM.  Since it doesn't
have CoW, I expect it to be similar to ext4 as far as this
codebase is concerned.  From what I recall years ago, unlink(2)
was slow on XFS with Maildirs, and it's also the case currently
with btrfs...

Another interesting bit: SQLite uses some F2FS-only APIs.  So
F2FS could be good for SSD users; but I've yet to try it...

I also don't know if network filesystems (Ceph, Gluster, NFS,
Lustre, AFS, ...) work at all.  Maybe they're fine for git
storage, but probably not with SQLite, Xapian or flock(2).

             reply	other threads:[~2020-08-05  3:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  3:11 Eric Wong [this message]
2020-08-06 17:32 ` what storage system(s) are you using? Konstantin Ryabitsev
2020-08-21 18:51   ` Eric Wong

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

  List information: https://public-inbox.org/README

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

  git send-email \
    --in-reply-to=20200805031127.GA11917@dcvr \
    --to=e@yhbt.net \
    --cc=meta@public-inbox.org \
    /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 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 read-only IMAP folder(s) and NNTP newsgroup(s).