"Whole disk and all partitions have page caches of their own." That's so bad. I can think of numerous cases where this will cause problems; including some I encountered last year and did not understand at the time. Manipulating EFI partitions through the whole disk device makes sense because FAT filesystems *know their offset on the disk*, and some of the existing tools really don't like being given a partition device. There's also the astounding: write stuff to disk, umount everything, copy one disk to another using the whole disk device doesn't work because reading the whole disk yields a stale cache (sometimes). On the other hand, I can think of very few cases where the file vs disk buffer pool matters, because the loop device is unaffected (writing to a loop block device is coherent with the file). On Sat, Aug 26, 2023 at 7:06 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Aug 26, 2023 at 06:25:58PM -0700, Joshua Hudson wrote: > > I am presuming you mean "Are you sure this not a hardware issue?" > > > > I am sure it is not, for two reasons. > > > > 1) If it were a hardware issue I would still expect the two device > > nodes (whole disk and partition) to report the *same* data. > > > > 2) I have since developed a workaround involving BLKFLSDEV. The > > workaround is really ugly. > > Whole disk and all partitions have page caches of their own. > There is no coherency between those; write through one, then > read through another and you are not guaranteed that read won't > see the stale cached data. > > Doctor, it hurts when I do it... > > Incidentally, read from device/write to the place you've read via > file/read from device again also has no coherency warranties, for > exact same reason. > > IOW, not a bug.
