[zfs-devel] Ping: reasoning in module/zfs/zfs_ctldir.c
adilger at dilger.ca
Wed Oct 12 17:13:55 EDT 2016
I think one of the major technical limitations of ZFS on 32-bit platforms was the limited vmalloc address space, since ZFS used vmalloc heavily for large data block buffers.
The ABD patches (not yet landed for 0.7.0) remove the need for vmalloc in the IO path, so ZFS should be much more usable on 32-bit platforms than before.
ZFS itself works fine with 32-bit systems (AFAIK, based on comments for BSD), so I don't think there is a fundamental objection to it, just a shortcoming in the Linux kernel that is making it more difficult, and a general lack of people who are using 32-bit CPUs these days.
If this is a area of interest to you, I would strongly recommend that you get the latest version of the ABD patch and test it on your platform and provide feedback to the developers. I suspect they will be generally helpful in response to any issues you find, but don't expect others to do extra work on a "fringe" platform if you aren't willing to put in some effort there yourself.
If this is of real interest to you (e.g. you depend on this working for some platform you support), you could even register a buildbot for your platform and run extended testing to ensure that regressions are not introduced with new patches.
> On Oct 12, 2016, at 05:01, u-odpp--- via zfs-devel <zfs-devel at list.zfsonlinux.org> wrote:
> Thanks for your comments Emmanuel!
> On Wed, Oct 12, 2016 at 11:15:58AM +0200, Emmanuel Kasper via zfs-devel wrote:
>>> Or possibly no developer 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.
>> I can't speak for everyone on this list, but I don't think there is
>> interest for ZFS in 32 bits platforms, due to the RAM requirements and
>> the 4GB limit.
> Hope my posting makes a point to the contrary (even if it possibly
> represents a minority).
>> AFAIK new 32bits deployment are mostly in the embedded space, and here
>> you would not use ZFS.
> I can not speak for the embedded space, but running ZFS on 32-bit is
> totally feasible and quite attractive, given that no other file system
> has the same combination of the useful features.
> I had possibilities to compare various file systems in varying practical
> scenarios and did not find any alternative to ZFS for the combination
> of flexibility, good performance, administration comfort and robustness
> against different kinds of data loss.
> It is a pity when an otherwise working configuration (32-bit Linux)
> is crippled without a good reason.
> This one "small" ctldir feature largely reduces the burden on the
> administrators and makes the users a lot happier, when the latter can
> use the usual file handling commands to access the historical data.
> Hope someone familiar with the code will find a moment to look at it,
> to rebut or confirm my best-effort conjecture that ctldir is not broken
> if enabled on 32-bit Linux, nor breaks anything else.
> zfs-devel mailing list
> zfs-devel at list.zfsonlinux.org
More information about the zfs-devel