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 th
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 thi
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 inst
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 i
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, 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).
Giving fi
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
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'
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 i
>
> 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 sen
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
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 allocati
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 1-
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 sen
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 hi
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-
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
> > > N
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 consensus
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 thin
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 muck
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
> > > N
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-con
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 an
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. Th
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
> pre-a
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 k
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 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 poo
37 matches
Mail list logo