[LU-137] ioctl passthrough mechanism for Lustre OST/MDT mountpoints

• Type: New Feature
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.16.0
• Affects Version/s: Lustre 2.1.0, Lustre 2.5.0
• Labels: patch
• Bugzilla ID: 14,489
• Assignee: Andreas Dilger
• Reporter: Andreas Dilger

Description

Implement an interface for sending IO Control (ioctl) commands from userspace through the Lustre mount point to the underlying ldiskfs filesystem to allow execution of filesystem-wide ioctl() commands, such as resize. This will allow user-space tools that operate via ioctl() commands on the filesystem mountpoint to be used on the Lustre MDT and OST filesystems while they are mounted and in use subject to any limitations of the original ioctl() commands themselves.

Issue Links

• is related to: LU-5822 health_check file not updating properly
• is related to: LU-4795 server_put_mount() calls server_deregister_mount() even if this isn't the last reference
• is related to: LU-8151 OST/MDT /proc/mounts always shows "ro" for server mountpoints
• is related to: LU-16835 lustre-initialization: Operation not supported while trying to set fs label, tune2fs 1.47.0-wc1
• is related to: LU-4931 New feature of giving server/storage side advice of accessing file
• is related to: LU-17027 missing #include <linux/file.h> in lustre/target/tgt_mount.c
• is related to: LU-6202 clean up ioctl handling
• is related to: LU-11355 Add Lustre trim support

Comments

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58450
Subject: LU-137 osd: better stat info for server mountpoints
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: dc0ae67cfd02662b863e86327bc8bcc98dcd7561

[Peter Jones]

Landed for 2.16. It's been a while since I closed a Jira ticket with a bugzilla id!

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/20161/
Subject: LU-137 osd-ldiskfs: pass through resize ioctl
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ac0380dc519aa15310670d164e98453861ef332a

[Andreas Dilger]

It may be that this has been fixed via patch https://review.whamcloud.com/33131 "Subject: LU-11355 lustre: enable fstrim on lustre device", which added a generic ioctl passthrough from userspace to ldiskfs.

However, the last time I had tested this (several years ago) there were also some issues with e2fsprogs/resize2fs being unhappy that the block device (st_rdev) reported by the Lustre server stub mount did not match the underlying block device. That is what patch: http://review.whamcloud.com/20161 "LU-137 osd: better stat info for server mountpoints" was about, but I haven't updated it in several years.

[James A Simmons]

Linking this since I plan on fixing the ioctl direction issue which will provide a proper interface for this as well.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/23092/
Subject: LU-137 obdclass: add dt_object_put() and use it
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 5963af745b3aa14410d5ceb66f8a7b7d6aaf576a

[Gerrit Updater]

Andreas Dilger ([e-mail]) uploaded a new patch: http://review.whamcloud.com/23092
Subject: LU-137 obdclass: add dt_object_put() and use it
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: cf4f59a5a7253e18ac98983216791cb730511d18

[Gerrit Updater]

Andreas Dilger ([e-mail]) uploaded a new patch: http://review.whamcloud.com/20161
Subject: LU-137 osd: better stat info for server mountpoints
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: db5b4aaa6177d9ab179b46a8d3e5d13c5d2c2883

[Andreas Dilger]

Alex, what about adding a new dt_ioctl() method for the OSD API? It would of course be fine if the underlying OSD doesn't support the given ioctl (e.g. returns -ENOTTY) but gives a way to add features like this. I see that this was handled for FIEMAP by adding a dbo_fiemap_get() method (though it could return -EOPNOTSUPP a LOT earlier in the request processing), but that might result in an explosion of different methods if we add one for every ioctl. Other candidates that we might need in the future include FITRIM to trim unallocated space for SSD or thin-provisioned devices, EXT4_IOC_PRECACHE_EXTENTS to prefetch file extent metadata, EXT4_IOC_MOVE_EXT or EXT4_IOC_MIGRATE for data migration within the OST.

It isn't yet clear to me if we want separate ioctl methods for the whole device and per file, or if it is OK to just do the "device" ioctls the root inode.

[Alex Zhuravlev]

I don't think you want to manage ZFS pools (or btrfs devices) directly. we can provide vfsmount or superblock via osd_conf_get(), but again that will work for ldiskfs only.