[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.
--
Thanks,
Brian
- Fwd: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Andrei Borzenkov, 2016/08/24
- Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Toomas Soome, 2016/08/24
- Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Brian Behlendorf, 2016/08/24
- Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Toomas Soome, 2016/08/24
- Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Andrei Borzenkov, 2016/08/24
- Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Toomas Soome, 2016/08/24
- Re: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool,
Brian Behlendorf <=
- RE: [bug #48885] zfs_mount fails with `org.zfsonlinux:large_dnode` enabled: Unsupported features in pool, Bass, Ned, 2016/08/24