On Thu, Feb 28, 2013 at 6:11 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > On Thu, 28 Feb 2013 23:54:13 +0100 > Björn JACKE <bj@xxxxxxxxx> wrote: > >> On 2013-02-28 at 07:26 -0800 Jeff Layton sent off: >> > NTFS doesn't support sparse files, so the OS has to zero-fill up to the >> > point where you're writing. That can take a looooong time on slow >> > storage (minutes even). >> >> but you are talking about FAT here, right? NTFS does support sparse files if >> the sparse bit has been explicitly been set on it. Bit even if the sparse bit >> is not set filling a file with zeros by writing after a seek long beyond the >> end of the file is very fast because NTFS supports that feature what Unix >> filesystems like xfs call extents. >> >> If writing beyond the end of a file is really slow via cifs vfs in the test >> case against a ntfs volume then I wonder if that operation is being really done >> optimally over the wire. ntfs really isn't that bad with handling this kind of >> files. >> > > I'm not sure since I don't know the internals of NTFS. I had always > assumed that it didn't really handle sparse files well (hence the > "rabbit-pellet" thing that windows clients do). > > All I can say however is that writes long past the EOF can take a > *really* long time to run. Typically we just issue a SMB_COM_WRITEX at > the offset to which we want to put the data. Is there some other way we > ought to be doing this? > > In any case, it doesn't really change the fact that there is no > guaranteed time of response from CIFS servers. They can easily take a > really long time to respond to certain requests. The best method we > have to deal with that is to periodically "ping" the server with an > echo to see if it's still there. SMB2/SMB3 with better async support may make this easier - but Jeff is right. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
