On Wed, Oct 12, 2016 at 10:40:34AM -0700, Brian Behlendorf wrote:
> Your impression is spot on. For the Linux implementation it was
> necessary to borrow a few inode numbers in order to construct the
> virtual .zfs directory. These number were chosen to be as large as
> possible, above 32-bits, to leave as much room for the real ZFS inodes
> as possible.
I saw this in the code, but it did not appear to me whether it would
necessarily hit the 32-bit limit by the regular ZFS-inodes as long as their
total number would remain below 2^32-<the-number-of-the-reserved-ones>.
> This functionality was then disabled for non 64-bit systems because when
> it was written Linux didn't have support for 64-bit inodes on 32-bit
> platforms. Now it does.
This makes my uncertainty about the inode number allocation strategy
irrelevant but I am still curious (my remark above), in case if you would
be inclined to enlighten me about the behaviour of the "highest allocated
I guess this is basicaly the question of whether/how the inode numbers
are freed/reused, given that they are allocated from the bottom up.
> These days there shouldn't be an major technical problem enabling this
> functionality on a 32-bit system running a modern kernel. I'd be
> interested to hear if you run in to any problems after enabling it.
Hope not, but surely I will tell
(and also if it goes well, then naturally somewhat later).
Thanks a lot for the clear answer Brian!
Now I feel confident to put this code into the production chain,
disabling the conditional in question.
> >> On Mon, Sep 26, 2016 at 3:00 AM, <u-r...@aetey.se> wrote:
> >>> Hope somebody would be willing to describe the details of what will break
> >>> on a 32-bit linux platform with the .zfs ctldir support enabled.
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com