Hi.
Some time ago I found:
/*
* MacOS X will fill in the 4-bit object type here.
*/
value = ZFS_DIRENT_MAKE(0, zp->z_id);
and:
objnum = ZFS_DIRENT_OBJ(zap.za_first_integer);
/*
* MacOS X can extract the object type here such as:
* uint8_t type = ZFS_DIRENT_TYPE(zap.za_first_integer);
*/
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) {
seems to fix it. Is this change ok or did I missue ''type'' part
of
za_first_integer field?
What I did was bascially:
/*
* MacOS X will fill in the 4-bit object type here.
*/
value = ZFS_DIRENT_MAKE(IFTODT(zp->z_phys->zp_mode), zp->z_id);
and:
objnum = ZFS_DIRENT_OBJ(zap.za_first_integer);
/*
* MacOS X can extract the object type here such as:
* uint8_t type = ZFS_DIRENT_TYPE(zap.za_first_integer);
*/
type = ZFS_DIRENT_TYPE(zap.za_first_integer);
Should I clear ''type'' somewhere maybe or is my change to
zap_value_search() correct? If the latter, can someone verify other uses
of za_first_integer?
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070422/0f1ccb9e/attachment.bin>
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? --matt
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). I don''t see easy fix for that. On Solaris struct dirent just doesn''t contain d_type field and ZFS doesn''t have a field indicating entry type in the zap structure. Will it be possible to store entry type also in Solaris in a way suggested for MacOS X? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070502/069e80f9/attachment.bin>
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