Messages in this thread | | | From | Dan Williams <> | Date | Wed, 5 Jan 2022 16:12:04 -0800 | Subject | Re: [PATCH v9 02/10] dax: Introduce holder for dax_device |
| |
On Wed, Jan 5, 2022 at 3:54 PM Darrick J. Wong <djwong@kernel.org> wrote: [..] > > Yes, I think we should just fail the holder registration and > > DAX+reflink unless the FS being mounted on a whole device. I know Ted > > and others had reservations about moving filesystems to be mounted on > > dax-devices directly, but hopefully the whole-block_device requirement > > is a workable middle ground? > > I think you have to be /very/ careful about that kind of statement -- > > Take ext4 for example. It has a lot of statically allocated ondisk > metadata. Someone could decide that it's a good idea to wire up a media > failure notification so that we shut down the fs if (say) a giant hole > opens up in the middle of the inode table. However, registering any > kind of media failure handler brings along this requirement for not > having partitions. > > This means that if ext4 finds a filesystem on a partition on a pmem > device and someone else has already registered a media failure handler, > it will have to choose between foregoing media failure notifications or > failing the mount outright.
...good example.
> Or you could support notification call chains...
We ended up with explicit callbacks after hch balked at a notifier call-chain, but I think we're back to that now. The partition mistake might be unfixable, but at least bdev_dax_pgoff() is dead. Notifier call chains have their own locking so, Ruan, this still does not need to touch dax_read_lock().
| |