2012-08-25 15:46, Sašo Kiselkov wrote:
The difference is that when you want to go fetch a block from a metaxel,
you still need some way to reference it. Either you use direct
references (i.e. ARC entries as above), or you use an indirect
mechanism, which means that for each read you will need to walk the
metaxel device, which is slow.

Um... how does your application (or the filesystem during its
metadata traversal) know that it wants to read a certain block?
IMHO, it has the block's address for that (likely known from
a higher-level "parent" block of metadata), and it requests -
"give me L bytes from offset O on tlvdev T", which is the layman
interpretation of DVA.

From what I understand, with ARC-cached blocks, we traverse the
RAM-based cache and find one with the requested DVA; then we
have its data already in RAM and return it to the caller.
If the block is not in ARC (and there's no L2ARC), we can fetch
it from the media using the DVA address(es?) we already know
from the request.
In case of L2ARC there is probably a non-null pointer to the
l2arc_buf_hdr_t, so we can request the block from the L2ARC.

If true, this is not faster than fetching the block from the
same SSD used as a metadata accelerator instead of being an
L2ARC device with a policy (or even without one, as today),
and in comparison only wasted RAM for the ARC entries.

BTW, as I see in "struct arc_buf_hdr", it only stores one DVA -
so I guess for blocks with multiple on-disk copies it is possible
to have them cached twice, or does ZFS always enforce storing and
seeking the ARC by a particular DVA of the block (likely DVA[0])?


If we do go with METAXELs as I described/proposed, and prefer
fetching metadata from SSD unless there are errors, then some
care should be taken to use this instance of DVA to reference
cached metadata blocks in the ARC.

//Jim Klimov
zfs-discuss mailing list

Reply via email to