Re: Ext3 vs NTFS performance

[Michael Tokarev <mjt@tls.msk.ru>]

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 because of  
>> this and the 1-byte writes are perfectly sensible in this regard.   
>> (Although a little odd as Windows has a proper API for doing  
>> preallocation so I don't get why it is not using that instead...)
> 
> 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 of writing zeroes, and we need to provide the
> infrastructure for them to do it, which is in progress currently.
> (And in fact samba already does the right thing for XFS if you use
> the prealloc samba vfs module, which AFAIK is not the default)

Hmm.

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).

Fixing this issue in samba means that samba has to keep/track more state
data than it currently does.  Detecting such seek+write has some costs.

It's even worse: imagine samba transforms this into write(zeros) (as
preallocate isn't available yet), and at the same time, another process
is writing there... Which will be perfectly valid in current case, but
will go wrong way (overwriting just-written data with zeros) in this
new scenario.

But the main point is that samba has to keep track of things which it
doesn't do now, and those things becomes.. interesting (difficult if
at all possible to track) in multi-user/concurrent-writes environment.

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/