On Mon, 2 May 2011 22:56:56 +0200 Jan Kara <jack@xxxxxxx> wrote: > So far, ext3 was allocating necessary blocks for mmapped writes when > writepage() was called. There are several issues with this. The worst > being that user is allowed to arbitrarily exceed disk quotas because > writepage() is called from flusher thread context (which is root) and thus > quota limits are ignored. Another bad consequence is that data is just lost > if we find there's no space on the filesystem during ->writepage() time. > > We solve these issues by implementing block reservation in page_mkwrite() > callback. We don't want to really allocate blocks on page_mkwrite() time > because for random writes via mmap (as seen for example with applications using > BerkeleyDB) it results in much more fragmented files and thus much worse > performance. So we allocate indirect blocks and reserve space for data block in > page_mkwrite() and do the allocation of data block from writepage(). Yes, instantiating the metadata and accounting the data is a good approach. The file layout will be a bit suboptimal, but surely that will be a minor thing. But boy, it's a complicated patch! Are we really sure that we want to make changes this extensive to our antiquated old fs? Or do we just say "yeah, it's broken with quotas - use ext4"? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html