[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bq056nkl.fsf@frosties.localdomain>
Date: Thu, 07 Aug 2008 14:01:46 +0200
From: Goswin von Brederlow <goswin-v-b@....de>
To: linux-ext4@...r.kernel.org
Subject: Re: Porting Zfs features to ext2/3
Theodore Tso <tytso@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists