> Subject: Ext3 vs NTFS performance
>
> Hello all,
>
> I've been testing the NAS performance of ext3/Openfiler 2.2 against
> NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> video workloads. The Windows CIFS client will attempt a poor-man's
> pr
Subject: Ext3 vs NTFS performance
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file
Cabot, Mason B wrote:
Philip:
the best response I can offer is that we have traced the application's
file system accesses and seen no such one-byte writes occuring at that
level. They are generated somewhere below the application. Additionally,
while we have observed iTunes on Windows issuing
Jörn Engel <[EMAIL PROTECTED]> wrote:
> On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
>> Which means the right place to fix this is samba. Samba just need
>> to intersept lseek and pread/pwrite to never allocate sparse files
>> but do the right thing instead. Now what the right
Jörn Engel [EMAIL PROTECTED] wrote:
On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
Which means the right place to fix this is samba. Samba just need
to intersept lseek and pread/pwrite to never allocate sparse files
but do the right thing instead. Now what the right thing would
Cabot, Mason B wrote:
Philip:
the best response I can offer is that we have traced the application's
file system accesses and seen no such one-byte writes occuring at that
level. They are generated somewhere below the application. Additionally,
while we have observed iTunes on Windows issuing
On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
>
> Which means the right place to fix this is samba. Samba just need
> to intersept lseek and pread/pwrite to never allocate sparse files
> but do the right thing instead. Now what the right thing would probably
> be a preallocate
On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
Which means the right place to fix this is samba. Samba just need
to intersept lseek and pread/pwrite to never allocate sparse files
but do the right thing instead. Now what the right thing would probably
be a preallocate instead
2007/5/6, Bodo Eggert <[EMAIL PROTECTED]>:
Theodore Tso <[EMAIL PROTECTED]> wrote:
> But as has already been discussed on this thread, in situations where
> the fileserver is under high memory pressure, any filesystem (XFS or
> ext4) would still end up allocating blocks out of order, resulting
Andrew Morton writes:
"Cabot, Mason B" <[EMAIL PROTECTED]> wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the
Theodore Tso <[EMAIL PROTECTED]> wrote:
> But as has already been discussed on this thread, in situations where
> the fileserver is under high memory pressure, any filesystem (XFS or
> ext4) would still end up allocating blocks out of order, resulting in
> fragmentation. Explicit preallocation,
On Fri, May 04, 2007 at 07:49:13PM +0400, Michael Tokarev wrote:
> How about providing a way to stop kernel (or filesystem) to make gaps
> in files instead? Like some ioctl(fd, FS_NOGAPS, 1) -- pretty much
> like 'doze has, just the opposite (on windows, this flag is "on" by
> default).
Giving
On Sat, May 05, 2007 at 11:13:36AM +0800, Xu CanHao wrote:
> On 5 Mai, 10:20, Theodore Tso <[EMAIL PROTECTED]> wrote:
> >
> >This is being worked on already. XFS has a per-filesystem ioctl, but
> >we want to create a filesystem-independent system call,
> >sys_fallocate(), that would wired into
On Sat, May 05, 2007 at 11:13:36AM +0800, Xu CanHao wrote:
On 5 Mai, 10:20, Theodore Tso [EMAIL PROTECTED] wrote:
This is being worked on already. XFS has a per-filesystem ioctl, but
we want to create a filesystem-independent system call,
sys_fallocate(), that would wired into the already
On Fri, May 04, 2007 at 07:49:13PM +0400, Michael Tokarev wrote:
How about providing a way to stop kernel (or filesystem) to make gaps
in files instead? Like some ioctl(fd, FS_NOGAPS, 1) -- pretty much
like 'doze has, just the opposite (on windows, this flag is on by
default).
Giving
Theodore Tso [EMAIL PROTECTED] wrote:
But as has already been discussed on this thread, in situations where
the fileserver is under high memory pressure, any filesystem (XFS or
ext4) would still end up allocating blocks out of order, resulting in
fragmentation. Explicit preallocation, as
Andrew Morton writes:
Cabot, Mason B [EMAIL PROTECTED] wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the
2007/5/6, Bodo Eggert [EMAIL PROTECTED]:
Theodore Tso [EMAIL PROTECTED] wrote:
But as has already been discussed on this thread, in situations where
the fileserver is under high memory pressure, any filesystem (XFS or
ext4) would still end up allocating blocks out of order, resulting in
On Tue, 1 May 2007 13:43:18 -0700
"Cabot, Mason B" <[EMAIL PROTECTED]> wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a
On Fri, May 04, 2007 at 07:49:13PM +0400, Michael Tokarev wrote:
>
> How about providing a way to stop kernel (or filesystem) to make gaps
> in files instead? Like some ioctl(fd, FS_NOGAPS, 1) -- pretty much
> like 'doze has, just the opposite (on windows, this flag is "on" by
> default).
This
>
> Cabot, Mason B wrote:
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly
> outperforms ext3 for
> > video workloads. The Windows CIFS client will attempt a poor-man's
> > pre-allocation of the file on the server by
On Fri, May 04, 2007 at 08:23:08AM -0400, Theodore Tso wrote:
> On Thu, May 03, 2007 at 02:14:52PM -0700, Valerie Henson wrote:
>
> > I'd really like to see a generic VFS-level detection of
> > read()/write()/creat()/mkdir()/etc. patterns which could detect things
> > like "Oh, this file is
Cabot, Mason B wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file on the server by sending 1-byte writes at
Christoph Hellwig wrote:
> On Fri, May 04, 2007 at 09:12:31AM +0100, Anton Altaparmakov wrote:
>> Nothing to do with win32 functions. Windows does NOT create sparse
>> files therefore it never can have an issue like ext3 does in this
>> scenario. Windows will cause nice allocations to happen
On 4 May 2007, at 10:46, Christoph Hellwig wrote:
On Fri, May 04, 2007 at 09:12:31AM +0100, Anton Altaparmakov wrote:
Nothing to do with win32 functions. Windows does NOT create sparse
files therefore it never can have an issue like ext3 does in this
scenario. Windows will cause nice
On Thu, May 03, 2007 at 02:14:52PM -0700, Valerie Henson wrote:
> But in terms of what we should do to fix it, there is the possibility
> of some debate. In general, I think there is a lot of code stuck down
> in individual file systems - especially in XFS - that could be
> usefully hoisted up to
On Fri, May 04, 2007 at 09:12:31AM +0100, Anton Altaparmakov wrote:
> Nothing to do with win32 functions. Windows does NOT create sparse
> files therefore it never can have an issue like ext3 does in this
> scenario. Windows will cause nice allocations to happen because of
> this and the
On 3 May 2007, at 23:40, Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
For this particular case, Ted is probably right and the only place
we'll ever see this insane poor man's pre-allocate pattern is from
the
Windows CIFS client, in which case fixing this in Samba makes
On 3 May 2007, at 23:40, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
For this particular case, Ted is probably right and the only place
we'll ever see this insane poor man's pre-allocate pattern is from
the
Windows CIFS client, in which case fixing this in Samba makes
On Fri, May 04, 2007 at 09:12:31AM +0100, Anton Altaparmakov wrote:
Nothing to do with win32 functions. Windows does NOT create sparse
files therefore it never can have an issue like ext3 does in this
scenario. Windows will cause nice allocations to happen because of
this and the
On Thu, May 03, 2007 at 02:14:52PM -0700, Valerie Henson wrote:
But in terms of what we should do to fix it, there is the possibility
of some debate. In general, I think there is a lot of code stuck down
in individual file systems - especially in XFS - that could be
usefully hoisted up to a
On 4 May 2007, at 10:46, Christoph Hellwig wrote:
On Fri, May 04, 2007 at 09:12:31AM +0100, Anton Altaparmakov wrote:
Nothing to do with win32 functions. Windows does NOT create sparse
files therefore it never can have an issue like ext3 does in this
scenario. Windows will cause nice
Christoph Hellwig wrote:
On Fri, May 04, 2007 at 09:12:31AM +0100, Anton Altaparmakov wrote:
Nothing to do with win32 functions. Windows does NOT create sparse
files therefore it never can have an issue like ext3 does in this
scenario. Windows will cause nice allocations to happen
Cabot, Mason B wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file on the server by sending 1-byte writes at
On Fri, May 04, 2007 at 08:23:08AM -0400, Theodore Tso wrote:
On Thu, May 03, 2007 at 02:14:52PM -0700, Valerie Henson wrote:
I'd really like to see a generic VFS-level detection of
read()/write()/creat()/mkdir()/etc. patterns which could detect things
like Oh, this file is likely to be
Cabot, Mason B wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly
outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file on the server by sending
On Fri, May 04, 2007 at 07:49:13PM +0400, Michael Tokarev wrote:
How about providing a way to stop kernel (or filesystem) to make gaps
in files instead? Like some ioctl(fd, FS_NOGAPS, 1) -- pretty much
like 'doze has, just the opposite (on windows, this flag is on by
default).
This is
On Tue, 1 May 2007 13:43:18 -0700
Cabot, Mason B [EMAIL PROTECTED] wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
In article <[EMAIL PROTECTED]> you wrote:
> For this particular case, Ted is probably right and the only place
> we'll ever see this insane poor man's pre-allocate pattern is from the
> Windows CIFS client, in which case fixing this in Samba makes sense -
> although I'm a bit horrified by the idea
On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
> On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
> > Hello all,
> >
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
>
On Thu, May 03, 2007 at 10:15:11AM +1000, David Chinner wrote:
[ bad fragmentation from a funky write one byte every 128k system ]
>
> This only becomes a problem if the system has enough pages dirty to
> be triggering throttling so that the 1byte writes are converted before
> the data actually
On Thu, May 03, 2007 at 10:15:11AM +1000, David Chinner wrote:
[ bad fragmentation from a funky write one byte every 128k system ]
This only becomes a problem if the system has enough pages dirty to
be triggering throttling so that the 1byte writes are converted before
the data actually hits
On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video
In article [EMAIL PROTECTED] you wrote:
For this particular case, Ted is probably right and the only place
we'll ever see this insane poor man's pre-allocate pattern is from the
Windows CIFS client, in which case fixing this in Samba makes sense -
although I'm a bit horrified by the idea of
David Chinner wrote:
> On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> > video workloads. The Windows CIFS client will attempt a
On Wed, May 02, 2007 at 03:46:21PM -0400, Chris Mason wrote:
> On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
> > On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
> > > Hello all,
> > >
> > > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > >
On Wed, May 02, 2007 at 04:38:55PM -0400, Jeff Garzik wrote:
> > I think we mostly have consensus on a calling convention which
> >all of the architectures (s390, power, arm, ia64, etc.); of course
> >then we will need to get glibc to support the new system call.
>
> glibc has had support for
Theodore Tso wrote:
FYI, we are currently closing on a new system call so that
glibc's fallocate() will be able to call into the appropriate
per-filesystem routines in a portable way, since ext4 will have
persistent preallocation support.
Yep.
I think we mostly have
On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
> On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
> > Hello all,
> >
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
>
On Wed, May 02, 2007 at 11:08:10AM -0700, Jeremy Allison wrote:
> > The right place is clearly Samba. I can't think of any other program
> > or filesystem protocol where writing a 1 byte write at 128k strides
> > would be used to signal a desire to do preallocation. In fact, it's
> > hard to
On Wed, May 02, 2007 at 08:40:35PM +0200, Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
>
> > On Wed, May 02, 2007 at 02:21:40PM +0200, Andi Kleen wrote:
> > > Andrew Morton <[EMAIL PROTECTED]> writes:
> > > >
> > > > Conceivably we could address this in the filesystem without
On Wed, May 02, 2007 at 12:16:38PM -0400, Theodore Tso wrote:
> On Tue, May 01, 2007 at 02:23:25PM -0700, Andrew Morton wrote:
> > On Tue, 1 May 2007 13:43:18 -0700
> > "Cabot, Mason B" <[EMAIL PROTECTED]> wrote:
> >
> > > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > >
Theodore Tso <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2007 at 02:21:40PM +0200, Andi Kleen wrote:
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> > >
> > > Conceivably we could address this in the filesystem without mucking other
> > > things up. But I'd have thought the simplest
On Tue, May 01, 2007 at 02:23:25PM -0700, Andrew Morton wrote:
> On Tue, 1 May 2007 13:43:18 -0700
> "Cabot, Mason B" <[EMAIL PROTECTED]> wrote:
>
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> >
On Wed, May 02, 2007 at 02:21:40PM +0200, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > Conceivably we could address this in the filesystem without mucking other
> > things up. But I'd have thought the simplest damage-control would be to
> > detect this pattern in samba
On Tue, May 01, 2007 at 11:54:04PM -0400, Gerhard Mack wrote:
> On Tue, 1 May 2007, Cabot, Mason B wrote:
>
> > Hello all,
> >
> > I've been testing the NAS performance of ext3/Openfiler 2.2 against
> > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> > video workloads.
On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
> Hello all,
>
> I've been testing the NAS performance of ext3/Openfiler 2.2 against
> NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> video workloads. The Windows CIFS client will attempt a poor-man's
>
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> Conceivably we could address this in the filesystem without mucking other
> things up. But I'd have thought the simplest damage-control would be to
> detect this pattern in samba and to then use glibc's fallocate().
The advantage of detecting it in
Andrew Morton [EMAIL PROTECTED] writes:
Conceivably we could address this in the filesystem without mucking other
things up. But I'd have thought the simplest damage-control would be to
detect this pattern in samba and to then use glibc's fallocate().
The advantage of detecting it in kernel
On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
On Tue, May 01, 2007 at 11:54:04PM -0400, Gerhard Mack wrote:
On Tue, 1 May 2007, Cabot, Mason B wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows
On Wed, May 02, 2007 at 02:21:40PM +0200, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
Conceivably we could address this in the filesystem without mucking other
things up. But I'd have thought the simplest damage-control would be to
detect this pattern in samba and to then
On Tue, May 01, 2007 at 02:23:25PM -0700, Andrew Morton wrote:
On Tue, 1 May 2007 13:43:18 -0700
Cabot, Mason B [EMAIL PROTECTED] wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video
Theodore Tso [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:21:40PM +0200, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
Conceivably we could address this in the filesystem without mucking other
things up. But I'd have thought the simplest damage-control would be
On Wed, May 02, 2007 at 12:16:38PM -0400, Theodore Tso wrote:
On Tue, May 01, 2007 at 02:23:25PM -0700, Andrew Morton wrote:
On Tue, 1 May 2007 13:43:18 -0700
Cabot, Mason B [EMAIL PROTECTED] wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and
On Wed, May 02, 2007 at 08:40:35PM +0200, Andi Kleen wrote:
Theodore Tso [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:21:40PM +0200, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
Conceivably we could address this in the filesystem without mucking
other
On Wed, May 02, 2007 at 11:08:10AM -0700, Jeremy Allison wrote:
The right place is clearly Samba. I can't think of any other program
or filesystem protocol where writing a 1 byte write at 128k strides
would be used to signal a desire to do preallocation. In fact, it's
hard to think of a
On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video
Theodore Tso wrote:
FYI, we are currently closing on a new system call so that
glibc's fallocate() will be able to call into the appropriate
per-filesystem routines in a portable way, since ext4 will have
persistent preallocation support.
Yep.
I think we mostly have
On Wed, May 02, 2007 at 04:38:55PM -0400, Jeff Garzik wrote:
I think we mostly have consensus on a calling convention which
all of the architectures (s390, power, arm, ia64, etc.); of course
then we will need to get glibc to support the new system call.
glibc has had support for a
On Wed, May 02, 2007 at 03:46:21PM -0400, Chris Mason wrote:
On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote:
On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and
David Chinner wrote:
On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
On Tue, 1 May 2007, Cabot, Mason B wrote:
> Hello all,
>
> I've been testing the NAS performance of ext3/Openfiler 2.2 against
> NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> video workloads. The Windows CIFS client will attempt a poor-man's
> pre-allocation of the
On Tue, 1 May 2007 13:43:18 -0700
"Cabot, Mason B" <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've been testing the NAS performance of ext3/Openfiler 2.2 against
> NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
> video workloads. The Windows CIFS client will attempt a
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file on the server by sending 1-byte writes at
128K-byte
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file on the server by sending 1-byte writes at
128K-byte
On Tue, 1 May 2007 13:43:18 -0700
Cabot, Mason B [EMAIL PROTECTED] wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
On Tue, 1 May 2007, Cabot, Mason B wrote:
Hello all,
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the file on
78 matches
Mail list logo
