On Sat, Jan 02, 2016 at 10:56:36AM +0000, Sitsofe Wheeler wrote: > 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? posix_fadvise(fd, offset, len, POSIX_FADV_DONTNEED); should work. > > 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) It's fine, because the data size (sizeof(struct blkzeroout2)) and direction are encoded in the full ioctl number definition. --D > > > 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
