On Wed, Mar 14, 2012 at 02:27:09PM +1100, Dave Chinner wrote: > > If the answer to #2 is not C, it would appear there's no atomic way to > > indicate that I'm done with certain data* but I want the filesystem to > > continue to guarantee space for me. Is this correct? > > Not through fallocate() right now. XFS has an ioctl that will turn > written ranges and holes back into preallocated space: > XFS_IOC_ZERO_RANGE. I've got a patch that introduces this zeroing > capability to fallocate (see below) which currently works on XFS. If this is something that an important application or set of applications really want, maybe we should provide an interface through fallocate(2) TO DO THIS. > > * so the filesystem can send a TRIM/UNMAP to an underlying SSD. > > It does not, however, issue discards on the range, because it is > still allocated space in the filesystem. It could probably be > made to do so, especially as the folks that requested the > XFS_IOC_ZERO_RANGE functionality asking about extending it to do > this last week. ... and if we know that discards will persistently cause blocks to return zero (the device exports a flag indicating whether this is true), and that trims are fast (i.e., they export the SATA 3.1 queable trim command), it might make sense to simply issue a discard on the range and not even mess with the metadata flags (since messing with the metadata flags has overhead at punch time and the next time oyu want to write to that block). The choice of what to do should be hidden from the application, though and be handled at the file system level. - 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
