From: Goswin von Brederlow <goswin-v-b@web.de>
To: linux-ext4@vger.kernel.org
Subject: Re: Porting Zfs features to ext2/3
Date: Thu, 07 Aug 2008 14:01:46 +0200 [thread overview]
Message-ID: <87bq056nkl.fsf@frosties.localdomain> (raw)
In-Reply-To: <20080727233855.GB9378@mit.edu> (Theodore Tso's message of "Sun, 27 Jul 2008 19:38:55 -0400")
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Jul 27, 2008 at 04:54:41PM -0600, Eric Anopolsky wrote:
>> On Sun, 2008-07-27 at 01:49 -0700, postrishi wrote:
>> > Hello
>> >
>> > I want to know that has any work been done to port the Zfs features to
>> > ext2/3
>>
>> Did you know that ZFS is available for Linux?
>
> ZFS is available in a FUSE filesystem. As a userspace filesystem, it
> means a huge number of context switches to get data between the disk,
> to the kernel, to the FUSE userspace, back to the kernel, and to the
> process trying to access the ZFS file. That's not going to be high
> performance. For someone who wants to migrate from Solaris to Linux,
> it might be useful, but I'm not sure you would really want to use a
> ZFS/FUSE implementation in production.
In most situations the limiting factor is the users
harddisk. Esspecially for metadata the seek time is the real limiting
factor. In the case of ZFS there is another big factor though, the
checksumming. A kernel implementation could use the async crypto
engine and take advantage of hardware checksumming.
To truely compete with a kernel ZFS there would have to be an
interface for passing data to the crypto engine from
userspace. Combine that with splice or some other zero copy solution
and the performance will be mostly the same.
On the other hand never forget how complex the filesystem code is in
the kernel. One of the biggest advantages of fuse is the simplicity of
the code. As such it is much easier to get the codebase stable.
MfG
Goswin
prev parent reply other threads:[~2008-08-07 12:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-27 8:49 Porting Zfs features to ext2/3 postrishi
2008-07-27 22:49 ` Theodore Tso
2008-07-27 22:49 ` Shehjar Tikoo
2008-07-27 23:37 ` Theodore Tso
2008-07-28 3:42 ` Shehjar Tikoo
2008-07-27 22:54 ` Eric Anopolsky
2008-07-27 23:38 ` Theodore Tso
2008-07-28 4:15 ` Eric Anopolsky
2008-07-28 12:40 ` Theodore Tso
2008-07-29 3:58 ` Eric Anopolsky
2008-07-29 16:46 ` Ric Wheeler
2008-07-30 6:00 ` Eric Anopolsky
2008-07-29 21:00 ` Szabolcs Szakacsits
2008-07-29 22:52 ` Szabolcs Szakacsits
2008-07-30 1:29 ` Theodore Tso
2008-08-07 12:09 ` Goswin von Brederlow
2008-07-30 1:34 ` Theodore Tso
2008-07-31 0:50 ` Szabolcs Szakacsits
2008-08-04 20:38 ` Szabolcs Szakacsits
2008-08-07 12:01 ` Goswin von Brederlow [this message]
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=87bq056nkl.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=linux-ext4@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