Discussion:
modified mdb and zdb
Jim Klimov
2013-11-12 11:09:29 UTC
Permalink
I'm studying zfs on Solaris 10.I read ZFS On-Disk Specification and try to find my data, but i found something wrong.
The dnode_phys_t of object_phys_t don't point to an array of dnode_phys_t, it point to an array of blkptr_t.
I am not ready to go into such depths responsibly, but can offer my
understanding below. Really, this is better asked on the illumos ZFS
list (Oracle's one is pretty quiet). I might guess however that many
objects in ZFS are extensible (with "bonus data") which is interpreted
based on the value of some flag in the main standard structure.

AFAIK, the file storage (the metadata tree below a POSIX directory
entry) contains an optional number of levels of dnodes (up to 16Kb)
which include blkptr_t's that point to lower-level blocks (either
another layer of dnodes, or in case of L0 blocks - to "userdata").
This per-file tree of dnodes only depends on the size of file and
the number of blocks needed to allocate its data, and is (re)built
automatically when the file is written to.
Does it depend on the version of ZFS or Solaris?
Such basic things - should not. While the on-disk spec is old (2006)
and many things were expanded (differently in later branches of
proprietary and open ZFS implementations), the foundations should
be the same for the sake of backward compatibility (new code can
read old pools).

HTH, and more luck on the list,
//Jim Klimov
Matthew Ahrens
2013-11-12 19:00:21 UTC
Permalink
Post by Jim Klimov
I'm studying zfs on Solaris 10.I read ZFS On-Disk Specification and try
to find my data, but i found something wrong.
The dnode_phys_t of object_phys_t don't point to an array of
dnode_phys_t, it point to an array of blkptr_t.
That's correct, the blkptr_t in objset_phys_t's os_meta_dnode.dn_blkptr
points to an indirect block, which is an array of blkptr_t. However, this
object (the "dnode object") contains an array of dnode_phys_t. I.e. its
data blocks contain an array of dnode_phys_t, while its indirects blocks
are by definition an array of blkptr_t. You could say that the objset's
dnode_phys_t indirectly points to an array of dnode_phys_t.

--matt
Post by Jim Klimov
I am not ready to go into such depths responsibly, but can offer my
understanding below. Really, this is better asked on the illumos ZFS
list (Oracle's one is pretty quiet). I might guess however that many
objects in ZFS are extensible (with "bonus data") which is interpreted
based on the value of some flag in the main standard structure.
AFAIK, the file storage (the metadata tree below a POSIX directory
entry) contains an optional number of levels of dnodes (up to 16Kb)
which include blkptr_t's that point to lower-level blocks (either
another layer of dnodes, or in case of L0 blocks - to "userdata").
This per-file tree of dnodes only depends on the size of file and
the number of blocks needed to allocate its data, and is (re)built
automatically when the file is written to.
Does it depend on the version of ZFS or Solaris?
Such basic things - should not. While the on-disk spec is old (2006)
and many things were expanded (differently in later branches of
proprietary and open ZFS implementations), the foundations should
be the same for the sake of backward compatibility (new code can
read old pools).
HTH, and more luck on the list,
//Jim Klimov
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/
21635000-ebd1d460
Modify Your Subscription: https://www.listbox.com/
member/?&
Powered by Listbox: http://www.listbox.com
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com
Jim Klimov
2013-11-13 03:39:58 UTC
Permalink
In addition, where can i find the soure code ?
I can't open the page of http://www.opensolaris.org/os/community/zfs/source/ .
Yes, Oracle closed it some time ago. For current codebase of Open ZFS
(and illumos kernel code) see around here:
http://src.illumos.org/source/xref/illumos-gate/usr/src/common/zfs/

For building the whole project (kernel+zfs) see here:
http://wiki.illumos.org/display/illumos/How+To+Build+illumos

HTH,
//Jim Klimov
黄奕
2013-11-13 02:59:34 UTC
Permalink
In addition, where can i find the soure code ?
I can't open the page of http://www.opensolaris.org/os/community/zfs/source/ .
Post by Jim Klimov
I'm studying zfs on Solaris 10.I read ZFS On-Disk Specification and try to find my data, but i found something wrong.
The dnode_phys_t of object_phys_t don't point to an array of dnode_phys_t, it point to an array of blkptr_t.
I am not ready to go into such depths responsibly, but can offer my
understanding below. Really, this is better asked on the illumos ZFS
list (Oracle's one is pretty quiet). I might guess however that many
objects in ZFS are extensible (with "bonus data") which is interpreted
based on the value of some flag in the main standard structure.
AFAIK, the file storage (the metadata tree below a POSIX directory
entry) contains an optional number of levels of dnodes (up to 16Kb)
which include blkptr_t's that point to lower-level blocks (either
another layer of dnodes, or in case of L0 blocks - to "userdata").
This per-file tree of dnodes only depends on the size of file and
the number of blocks needed to allocate its data, and is (re)built
automatically when the file is written to.
Does it depend on the version of ZFS or Solaris?
Such basic things - should not. While the on-disk spec is old (2006)
and many things were expanded (differently in later branches of
proprietary and open ZFS implementations), the foundations should
be the same for the sake of backward compatibility (new code can
read old pools).
HTH, and more luck on the list,
//Jim Klimov
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.c
黄奕
2013-11-13 02:36:06 UTC
Permalink
I just signed up in Listbox, but after 30mins, I didn't receive the verification email still.
I'm all at sea.
Post by Jim Klimov
I'm studying zfs on Solaris 10.I read ZFS On-Disk Specification and try to find my data, but i found something wrong.
The dnode_phys_t of object_phys_t don't point to an array of dnode_phys_t, it point to an array of blkptr_t.
I am not ready to go into such depths responsibly, but can offer my
understanding below. Really, this is better asked on the illumos ZFS
list (Oracle's one is pretty quiet). I might guess however that many
objects in ZFS are extensible (with "bonus data") which is interpreted
based on the value of some flag in the main standard structure.
AFAIK, the file storage (the metadata tree below a POSIX directory
entry) contains an optional number of levels of dnodes (up to 16Kb)
which include blkptr_t's that point to lower-level blocks (either
another layer of dnodes, or in case of L0 blocks - to "userdata").
This per-file tree of dnodes only depends on the size of file and
the number of blocks needed to allocate its data, and is (re)built
automatically when the file is written to.
Does it depend on the version of ZFS or Solaris?
Such basic things - should not. While the on-disk spec is old (2006)
and many things were expanded (differently in later branches of
proprietary and open ZFS implementations), the foundations should
be the same for the sake of backward compatibility (new code can
read old pools).
HTH, and more luck on the list,
//Jim Klimov
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by

Loading...