[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd9320b30708292327u26f30c75j8e34b9fa1584371f@mail.gmail.com>
Date: Wed, 29 Aug 2007 23:27:58 -0700
From: mike <mike503@...il.com>
To: "Jeffrey W. Baker" <jwbaker@....org>
Cc: zfs-discuss@...nsolaris.org, xfs@....sgi.com,
linux-ext4@...r.kernel.org
Subject: Re: [zfs-discuss] ZFS, XFS, and EXT4 compared
On 8/29/07, Jeffrey W. Baker <jwbaker@....org> wrote:
> I have a lot of people whispering "zfs" in my virtual ear these days,
> and at the same time I have an irrational attachment to xfs based
> entirely on its lack of the 32000 subdirectory limit. I'm not afraid of
> ext4's newness, since really a lot of that stuff has been in Lustre for
> years. So a-benchmarking I went. Results at the bottom:
>
> http://tastic.brillig.org/~jwb/zfs-xfs-ext4.html
>
> Short version: ext4 is awesome. zfs has absurdly fast metadata
> operations but falls apart on sequential transfer. xfs has great
> sequential transfer but really bad metadata ops, like 3 minutes to tar
> up the kernel.
>
> It would be nice if mke2fs would copy xfs's code for optimal layout on a
> software raid. The mkfs defaults and the mdadm defaults interact badly.
this is cool to see. however, performance wouldn't be my reason for
moving to zfs. the inline checksumming and all that is what i want. if
someone could get nearly incorruptable filesystems (or just a linux
version of zfs... btrfs looks promising) this would be even better.
sadly ext4+swraid isn't as good, i might have tried that since waiting
the right hardware support for zfs for me seems to be unknown at this
point.
-
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