Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Joe Peterson <lavajoe@gentoo.org>
To: Thomas King <kingttx@tomslinux.homelinux.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Future Linux filesystems
Date: Tue, 03 Jun 2008 09:02:54 -0600	[thread overview]
Message-ID: <48455D1E.8010006@gentoo.org> (raw)
In-Reply-To: <9885.143.166.226.57.1212503847.squirrel@tomslinux.homelinux.org>

Thomas King wrote:
>> All the issues he complains about actually are solved by XFS, and XFS actually
> does better in
>> exactly these environments than either zfs on Solaris or JFS2 on AIX.
>>
>>
> 
> I asked the author that question and he states XFS is actually a pretty good
> answer to most of those issues but believes it still falls short where "the
> metadata areas are not aligned with RAID strips and allocation units are FAR too
> small but better than ext." Another detail he brought out was sending data and
> metadata to different devices in those environments and referenced RT XFS.
> Otherwise having them on the same device increases the possibility of corruption
> and/or a longer filesystem check/repair. Will btrfs offer something like this in
> the future?
> 
> Do y'all foresee btrfs being used in exabtye installations?
> Does/Will btrfs have RAID awareness in that it will align "the
> superblock and metadata to the RAID stripe"?
> What is the largest block allocation available?
> Will btrfs be T10 DIF/block protect aware?
> I remember reading that CRFS relies on btrfs, but will btrfs support NFS,
> specifically version 4.1?

You don't mention what I believe is the *key* issue (and I don't think
the author did either, but I skimmed his article): data integrity.  I'm
not talking about blatant failures or known need for an fsck, but rather
silent corruption.

Where I work, we are considering multi-petabyte scenarios, and with the
specs of current drives, we are talking hundreds of silent errors per
read of the volume of data - unacceptable.  With large filesystems (and
he's talking 100 PB, etc.), this is the #1 issue for me.

						-Joe

  reply	other threads:[~2008-06-03 15:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02 21:46 Future Linux filesystems Thomas King
     [not found] ` <20080603065205.GA19533@infradead.org>
2008-06-03 14:37   ` Thomas King
2008-06-03 15:02     ` Joe Peterson [this message]
2008-06-03 16:06       ` Martin K. Petersen
2008-06-03 16:46         ` Joe Peterson
2008-06-03 15:52     ` Evgeniy Polyakov
2008-06-03 16:17       ` Miguel Sousa Filipe
2008-06-04  2:14     ` Chris Mason
2008-06-04 14:00       ` Thomas King
2008-06-04  2:34     ` Dongjun Shin
  -- strict thread matches above, loose matches on Subject: below --
2008-06-11  9:38 Tomasz Chmielewski
2008-06-11 16:27 ` Zach Brown

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=48455D1E.8010006@gentoo.org \
    --to=lavajoe@gentoo.org \
    --cc=kingttx@tomslinux.homelinux.org \
    --cc=linux-btrfs@vger.kernel.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