On Tue, Apr 02, 2024 at 08:19:10PM -0700, Darrick J. Wong wrote: > On Wed, Apr 03, 2024 at 12:59:22PM +1100, Dave Chinner wrote: > > On Tue, Apr 02, 2024 at 06:39:03PM -0700, Darrick J. Wong wrote: > > > On Tue, Apr 02, 2024 at 08:10:15PM -0400, Colin Walters wrote: > > > > >> I hesitate to say it but maybe there should be some ioctl for online > > > > >> repair use cases only, or perhaps a new O_NOVERITY special flag to > > > > >> openat2()? > > > > > > > > > > "openat2 but without meddling from the VFS"? Tempting... ;) > > > > > > > > Or really any lower level even filesystem-specific API for the online > > > > fsck case. Adding a blanket new special case for all CAP_SYS_ADMIN > > > > processes covers a lot of things that don't need that. > > > > > > I suppose there could be an O_NOVALIDATION to turn off data checksum > > > validation on btrfs/bcachefs too. But then you'd want to careful > > > controls on who gets to use it. Maybe not liblzma_la-crc64-fast.o. > > > > Just use XFS_IOC_OPEN_BY_HANDLE same as xfs_fsr and xfsdump do. The > > handle can be build in userspace from the inode bulkstat > > information, and for typical inode contents verification purposes we > > don't actually need path-based open access to the inodes. That would > > then mean we can simple add our own open flag to return a fd that > > can do data operations that short-circuit verification... > > Heh, ok. Are there any private flags that get passed via > xfs_fsop_handlereq_t::oflags? Or does that mean defining a top level > O_FLAG that cannot be passed through openat but /can/ be sent via > open_by_handle? AIUI, open flags are arch specific, but I don't think any use the high bits of the 32 bit space they are defined in. So I think we could probably use the high bits in that field for our own purposes and not get conflicts with generic open flags... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
