On Mon, 2013-02-18 at 20:36 +0900, OGAWA Hirofumi wrote: > Andrew Bartlett <abart...@samba.org> writes:
> > Or, if we cannot make any changes to the on-disk format, what about > > keeping such a database in memory, allocating some of the existing free > > list to files that have had fallocate() called on them? (Naturally, > > this makes it non-persistent, and instead more of a 'hint', but could at > > least solve our mutual performance issues). > > [...] > > Hm. My concerns are compatibility and reliability. Although We can > change on-disk format if need, but I don't think it can be compatible > and reliable. If so, who wants to use it? I feel there is no reason to > use FAT if there is no compatible. > > Well, anyway, possible solution would be, we can pre-allocate physical > blocks via fallocate(2) or something, but discard pre-allocated blocks > at ->release() (or before unmount at least). This way would have > compatibility (no on-disk change over unmount) and possible breakage > would be same with normal extend write patterns on kernel crash > (i.e. Windows or fsck will truncate after i_size). That would certainly give me what the Samba NAS with USB FAT disk use case needs. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://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/