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.

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.

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.


On 10/12/2016 01:27 AM, wrote:
> On Tue, Oct 11, 2016 at 09:18:11PM -0700, Matthew Ahrens wrote:
>> I'm not sure, I don't see that restriction in the illumos zfs_ctldir.c.
>> This is speculation, but it may be that on linux the inode number of stuff
>> in .zfs/snapshot has the high bits set (above bit 32), and that doesn't
>> work on 32-bit?
> Thanks Matthew,
> Yes, the restriction is linux-specific but I got no answer on the
> @zfsonlinux list.
> My impression is that whoever wrote that code wanted to be cautious
> and also avoid the burden of analysis and maintenance for the 32-bit case.
> Nevertheless as I wrote I did not find any apparent issues in the code
> nor in practice, having built with ctldir enabled (but not heavily tested).
> I can think that no developer really cares about the 32-linux platform,
> assuming that ZFS is "only" interesting for large storage installations
> where one of course picks 64-bit servers.
> This unfortunately hurts a non-neglectable usage niche, where we handle
> moderate amounts of data on 32-bit kernels but still need the robustness
> and the administration advantages of zfs. This may become a reason for
> switching to a different kernel, but it would be nice to know whether
> the linux limitation is there for real.
> (at least, nice that someone was listening here! :)
> Best regards,
> Rune
>> On Mon, Sep 26, 2016 at 3:00 AM, <> 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.
>>> A brief reading of the code did not reveal to me anything that apparently
>>> would become wrong, even though the comment in the file says that the
>>> ctldir must be disabled on 32-bit.
>>> Nor does a 32-bit build with ctldir enabled readily crash or corrupt data.
>>> Would anybody who is familiar with the underlying structures explain why
>>> it would be hard (or what is needed) to enable the functionality for a
>>> 32-bit linux environment?


RSS Feed:
Modify Your Subscription:
Powered by Listbox:

Reply via email to