Re: [PATCH] iomap: add a workaround for racy i_size updates on block devices

["Darrick J. Wong" <djwong@kernel.org>]

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@kernel.org>

--D