Re: Enable FFS extended attributes in GENERIC?

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Replying to myself:

There have been two objections

1) It should not cause trouble for filesystems not explicitely using -o
extattr: this is indeed the case. Because extended attributes are stored
in sparse files outside of the fileystem, it means filesystem structures
are not atered. And if one do not use extended attributes, the
corresponding code path is not used.

2) Extended attribute backing store should be repairable, like
quotacheck repaired quota spare files before QUOTA2: unfortunately the
situation is different. Quota files both hold the quota limits and the
usage tracking. quotacheck could recover the later but not the former.
And in the case of extended attributes, there is no usage to recover.

Shall I consider the objections have been addressed and move forward?
Any other objection?


Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:

> Hello
> 
> Is there any opposition to enable FFS extended attributes in 
> GENERIC? 
> 
> I have been using them for a while and it seems stable, The
> relevant code is only involved if the filesystem is explicitely 
> mounted with -o extattr, which means a bug will not affect people
> that do not use the feature.
> 
> The only issues are:
> - storage in sparse file (like ancient quota) means fsck do not
> know about it and cannot repair it.
> - dump/restore/pax ignore extended attributes (cp and mv preserve them)
> 
> It means FFS extended attributes in NetBSD are fragile and that one
> should be ready to loose them, but that leaves some reasonable usages.


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost