On Sat, Aug 14, 2010 at 01:56:25PM +0200, Christoph Hellwig wrote:
> Can you guys review you rely on a) in your filesystem and if yes help
> me to figure out a good way to replace it? All the callers look like
> they do not actually rely on it because they seem to wait for the
> actual block freeing metadata I/O beforehand, but I'm not sure.
In no journal mode we don't actually wait, but nothing is guaranteed
in w/o a journal mode with respect to what happens after a crash, so I
think we're good. For all file systems that use journalling, we have
to make sure transaction which freed the blocks is safely committed on
the disk platters before we can call trim, so what you're asking
should be guaranteed if the file system is otherwise correct wrt to
journalling --- or am I missing something?
Also, to be clear, the block layer will guarantee that a trim/discard
of block 12345 will not be reordered with respect to a write block
12345, correct?
And on SATA devices, where discard requests are not queued requests,
the ata layer will have to do a queue flush *before* the discard is
sent, right? But things should be a tiny bit better even with SATA
because we won't need to wait for the barrier to be acknowledged
before sending more write requests to the device. If I understand
things correctly, the main place where this will have benefit will be
for more advanced interfaces like SAS?
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
