On Mon, Sep 25, 2023 at 05:18:16PM +0200, Christoph Hellwig wrote: > On Mon, Sep 25, 2023 at 08:09:02AM -0700, Darrick J. Wong wrote: > > > + /* > > > + * This can happen if truncating the block device races > > > + * with the check in the caller as i_size updates on > > > + * block devices aren't synchronized by i_rwsem for > > > + * block devices. > > > > Why /are/ bdevs special like this (not holding i_rwsem during a > > truncate) anyway? Is it because we require the sysadmin to coordinate > > device shrink vs. running programs? > > It's not just truncate, they also don't hold a lock on write. Oh! So they don't. Heh. > I think the reason is that there is no such things as the block allocator > and block truncation that happens for block devices, they historically > had a fixed size, and at some point we allowed to change that size > by various crude means that are only slowly becoming more standardized > and formal. Real block device size changes are about 100% growing of > the device, as that is an actually useful feature. Shrinks OTOH are > usuall a "cute" hack: block drivers set the size to 0 stop I/O when they > are shut down. I've been wanting to replace that with an actual check > in the bdev fd I/O path for a while, but that would also mean the > shrinking case would still be around, just exercised a lot less. You call bdev shrink a cute hack, cloud tenants call it a cost-reducing activity, and cloud vendors call it a revenue opportunity because shrinking filesystems is un***** expensive in terms of CPU time and IO usage. ;) Anyway, I'm not going to argue with longstanding blockdev precedent. Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> --D
