Re: introduce bdev holder ops and a file system shutdown method v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 19, 2023 at 06:11:36AM +0200, Christoph Hellwig wrote:
> On Thu, May 18, 2023 at 10:00:12PM -0400, Theodore Ts'o wrote:
> > On Thu, May 18, 2023 at 06:23:09AM +0200, Christoph Hellwig wrote:
> > > Hi all,
> > > 
> > > this series fixes the long standing problem that we never had a good way
> > > to communicate block device events to the user of the block device.
> > > 
> > > It fixes this by introducing a new set of holder ops registered at
> > > blkdev_get_by_* time for the exclusive holder, and then wire that up
> > > to a shutdown super operation to report the block device remove to the
> > > file systems.
> > 
> > Thanks for working on this!  Is there going to be an fstest which
> > simulates a device removal while we're running fsstress or some such,
> > so we can exercise full device removal path?
> 
> 
> So the problem with xfstests is that there isn't really any generic
> way to remove a block device, and even less so to put it back.
> 
> xfstests has some scsi_debug based tests, maybe I can cook something up
> for that.  My testing has been with nvme, so another option would be
> to add nvme-loop support to xfstests and use that.  I'll see what I can
> do.

Could you make dm-error accept a 'message' telling it to invoke all
these bdev removal actions?  There's already a bunch of helpers in
fstests to make that less awful for test authors.

--D



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux