On Wed, Sep 17, 2008 at 04:02:12PM +0100, Jamie Lokier wrote: > > I'm not clear about something from the above description. > > If I were writing a journalling / tree-like filesystem, and I did > store data in blocks without encoding, but fsync() only waits for them > to be committed to journal, not their final destination, and also they > might be moved around - should I set DATA_ENCODED or not? (And should > I return the temporary location in the long-running journal since > that's the only place the data is committed at the time of the call?) I can imagine two ways of requiring this. One would be that you should only set DATA_ENCODED if you knew that the data had reached its final destination, possibly with some way of inducing the filesystem to wait until this had happened. The other approach would be to require in the specification that the filesystem would have to be unmounted at least once. I prefer the latter as it is much simpler, and the number of users who actually care about DATA_ENCODED is quite small. The other observation I would make is that for filesystems where "final location" has no meaning (i.e., a log structured filesystem where its log cleaner is constantly moving data blocks around for compaction and/or flash wear leveling purposes), it will probably need to set some bit that means LOCATION_UNSTABLE, as well as setting DATA_ENCODED. This is would be a little confusing since what DATA_ENCODED really means is, "application that might want to read this file contents on an unmounted filesystem --- think again". So maybe a better name would be NO_UNMOUNTED_IO. - Ted P.S. If such filesystems want to be used by boot loaders that need fixed bootstrap blocks, they would probably need to have a flag that pinned the data blocks and caused them not be moved by the log cleaner. Reiser3 had to have something like this to work for LILO, but iirc this was just to disable tail packing. Same concept, though; it was a specialized per-filesystem flag that was needed if that filesystem wanted to be used by a particular boot loader with direct (unmounted) I/O requirements to access bootstrap code/data. -- 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
