Re: [PATCH 4/4] ext4: Add fdatasync scalability optimization

On Tue, Oct 14, 2014 at 03:25:54PM +0400, Dmitry Monakhov wrote: > Christoph Hellwig writes: > > > Much of the bookkeeping here seems generic and should be in common > > code and not inside a filesystem. > Yes. But this means that I need to store flush_id inside generic inode > which likely will

Re: [PATCH 4/4] ext4: Add fdatasync scalability optimization

Christoph Hellwig writes: > Much of the bookkeeping here seems generic and should be in common > code and not inside a filesystem. Yes. But this means that I need to store flush_id inside generic inode which likely will be accepted negatively because VFS people do not like inode bloating. But if

Re: [PATCH 4/4] ext4: Add fdatasync scalability optimization

Much of the bookkeeping here seems generic and should be in common code and not inside a filesystem. -- 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 P

[PATCH 4/4] ext4: Add fdatasync scalability optimization

If block device support flush epoch generation we can optimize fsync by using following logic 1) track flush_idx on per-inode basis, update it inside end_io 2) During fsync we can compare inode's flush_idx and curent device's flush_idx. If device generation is newer than it means someone alre