[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabl

From: Brian Behlendorf
Subject: Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool
Date: Wed, 24 Aug 2016 15:06:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 08/24/2016 02:26 PM, Toomas Soome wrote:
>> On 25. aug 2016, at 0:04, Andrei Borzenkov <address@hidden> wrote:
>> 24.08.2016 23:10, Brian Behlendorf пишет:
>>> Thomas,
>>> You should be able to simply add 'org.zfsonlinux:large_dnode' to the
>>> list of supported features.  As long as the dataset property dnodesize
>>> is set to legacy there won't be any on-disk format changes.  The dnodes
>>> on disk will still be 512 bytes in size and it will just leverage some
>>> previously unused pad space in the dnode_phys_t.
>>> Since we were concerned about grub support the zfs command now prohibits
>>> users from setting the dnodesize property to a non-legacy value for
>>> datasets with the bootfs property set.
>> We have no way to restrict which filesystems users will access at boot
>> time. Can we check value of this property in grub?
> yes, this is exactly why the features for read list exist - if the pool is 
> adding entry there and boot loader does not have matching entry in its 
> implementation, you deny the access to pool. Which is exactly what did happen 
> for this user.
>>> It shouldn't be a huge amount of work to fully support large dnode in
>>> grub but simply allowing the feature flag and checking the property
>>> should be enough for the vast majority of use cases.
>> It sounds like simply allowing this feature may access filesystem with
>> incompatible on-disk format. Either we need additional checks for legacy
>> format or we need full support for new format.
> sounds reasonable. 

Fully supporting the new format would definitely be the best solution.

The on-disk format change is well explained in the large dnode commit
comment and I'm happy to help clarify anything which isn't clear.  The
patch at its simplest allows a 512b dnode to expand in to multiple 512b
slots of a 16k dnode dbuf.

I haven't done grub development before but I can definitely review any
proposed patch to add this support.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]