On Thu, Oct 25, 2007 at 10:18:02AM -0400, Jun'ichi Nomura wrote: > There is no guarantee that the I/O flowing through the device again. > The table might need be replaced again, but to do that, the resume > should have been completed to let the userspace know it. Then the first attempt to set the size could be made to fail (because it could not get the lock immediately) and the size could be set after the second resume instead. - Setting the size would lag behind the actual size the dm table was supporting, but (given the usage cases discussed) this would not matter. > bdget() in noflush suspend has a possibility of stall. So we cannot avoid fixing that: we require immediate return with failure instead of waiting. > OTOH, calling bdget() and i_size_write() outside of the lock > can cause race with other table swapping and may result in setting > wrong device size. If the size setting is removed from the lock, then it becomes "set the inode size to match the current size of the table" and races would not matter - each "set size" attempt would set it to the instantaneous live table size, not a cached value that could be out-of-date. Alasdair -- agk@xxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
