On Jan 9, 2014, at 6:41, Theodore Ts'o <tytso@xxxxxxx> wrote: > [Another design tangent: with SMR drives, it's clear that atime > updates are going to be a big deal. So the question is how much will > our users really care about atime. Can we just simply say, "use > noatime", or should we think about some way of handling atime updates > specially? (For example, we could track atime updates separately, and > periodically include in the journal a list of inode numbers and their > real atimes.) This is not something we should do early on --- it's > another later optional enhancement --- but it is something to think > about. We already have noatime and relatime, since atime hurts on spinning disks as well. It wouldn't be impossible to do the atime updates in the journal initially, and only write the inodes to their final resting place after enough have been accumulated. I think when there are many atime updates together (e.g. "grep -r") it will be reasonable to checkpoint them to the filesystem, and when there are only a few those inodes could be rewritten to the journal. I'm thinking the same could be done with data journaling for small files. It makes sense to write a small file's data to the journal, but write large file data directly to its final resting place. Cheers, Andreas -- 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
