Pawel Jakub Dawidek wrote:
> On Tue, May 01, 2007 at 05:48:15PM -0700, Matthew Ahrens wrote:
>> Pawel Jakub Dawidek wrote:
>>> so I started to use it. The thing is that it broke some functionality.
>>> For example 'zpool status -v' doesn't show file names anymore.
>>> I tracked it down to the zap_value_search() function and changing:
>>> if (za->za_first_integer == value) {
>>> into:
>>> if (ZFS_DIRENT_OBJ(za->za_first_integer) == value) {
>> This is essentially correct, although it breaks the layering (the ZAP
>> shouldn't have such intimate knowledge of the ZPL's usage). Better would be
>> to pass in a mask to
>> zap_value_search().
>>
>> But, this is certainly a bug, which I'll file shortly.
>>
>> Have you found any other functionality to break when you store the file type
>> in the directory entry?
>
> I think this whole mechanism of storing type should be revised, because
> when we move ZFS file system created on Solaris to FreeBSD/MacOSX,
> d_type will be set to 0 (DT_UNKNOWN).
Correct, Solaris does not store the file type in the directory entry, so
other operating systems will have to deal with that (MacOS already does).
> I don't see easy fix for that.
We can easily make Solaris store the file type in the directory entry.
We have the file type in the vnode/znode. Solaris' struct dirent only
limits us to not convey it to userland on Solaris; it does not constrain
the on-disk format.
However, old pools will still have some directory entries without the
type, so other operating systems will still have to deal with that (or
write code to go update them all).
--matt
