Hello Brian,

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
inode number".

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.

Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

Reply via email to