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
next prev parent 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