Does your 32-bit application actually use the inode numbers? Or is it just trying to read other metadata (such as filenames in a directory, file sizes, etc)? If it's the latter, you could use LD_PRELOAD to wrap the calls and return fake/mangled inode numbers (since the application doesn't care about them anyway). See here for more details: https://www.tcm.phy.cam.ac.uk/sw/inodes64.html -----Original Message----- From: Yan, Zheng <ukernel@xxxxxxxxx> Sent: Wednesday, October 16, 2019 8:07 PM To: Dan van der Ster <dan@xxxxxxxxxxxxxx> Cc: ceph-users <ceph-users@xxxxxxx> Subject: Re: CephFS and 32-bit Inode Numbers On Mon, Oct 14, 2019 at 7:19 PM Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: > > Hi all, > > One of our users has some 32-bit commercial software that they want to > use with CephFS, but it's not working because our inode numbers are > too large. E.g. his application gets a "file too big" error trying to > stat inode 0x40008445FB3. > > I'm aware that CephFS is offsets the inode numbers by (mds_rank + 1) * > 2^40; in the case above the file is managed by mds.3. > > Did anyone see this same issue and find a workaround? (I read that > GlusterFS has an enable-in32 client option -- does CephFS have > something like that planned?) > ceph-fuse has client_use_faked_inos option. When it is enabled, ceph-fuse maps 64bits inode numbers to 32bits. It works as long as client has less than 2^32 inodes cached. So far there is no kernel client counterpart. Regards Yan, Zheng > Thanks! > > Dan > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an > email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |