Hi, On Fri, Jan 01, 2016 at 12:35:43PM +0000, Sitsofe Wheeler wrote: > > When using the BLKZEROOUT ioctl what should be the impact on buffer > cache data? Is the caller expected to invalidate the cache and if so > how? Googling around shows the cache incoherence after BLKZEROOUT is already a known issue: http://thread.gmane.org/gmane.comp.file-systems.ext4/46413 http://thread.gmane.org/gmane.linux.kernel.api/16926/ One of the comments off the first thread (http://thread.gmane.org/gmane.comp.file-systems.ext4/46413/focus=89268 ) says that O_DIRECT should be used but is this in reference to other I/O that happens to the BLKZEROOUT device? In other words is there no way to make BLKZEROOUT call safe from userspace on current kernels if regular buffered I/O is going to come after the zeroing? The latter link introduces ioctl BLKZEROOUT2 which does invalidation. One question I have is should the ioctl have an identical sequence number (127) to the original BLKZEROOUT: #define BLKZEROOUT _IO(0x12,127) [...] +#define BLKZEROOUT2 _IOR(0x12, 127, struct blkzeroout2) > write_ones(fd) > os.fsync(fd) > print ioctl(fd, IOCTL_BLKZEROOUT, 'LL', 0, size) > os.fsync(fd) > print file_is_null(f) # Returns False > write_ones(fd) > print ioctl(fd, IOCTL_BLKFLSBUF, 'LL', 0, 0) > print ioctl(fd, IOCTL_BLKZEROOUT, 'LL', 0, size) > print file_is_null(f) # Returns True -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
