On Thu, 28 Feb 2013 23:54:13 +0100 Björn JACKE <b...@sernet.de> 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. -- Jeff Layton <jlay...@samba.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/