[Top] [All Lists]

Extended attribute caching questions

To: xfs@xxxxxxxxxxx
Subject: Extended attribute caching questions
From: Richard <rtroxell@xxxxxxxxx>
Date: Wed, 30 Sep 2009 13:42:03 -0700
Authentication-results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=rtroxell@xxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rtroxell@xxxxxxxxx; l=3095; q=dns/txt; s=sjiport05001; t=1254343339; x=1255552939; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Richard=20<rtroxell@xxxxxxxxx>|Subject:=20Extend ed=20attribute=20caching=20questions|Date:=20Wed,=2030=20 Sep=202009=2013:42:03=20-0700|Message-Id:=20<1254343323.4 670.3749.camel@rtroxell-laptop>|To:=20xfs@xxxxxxxxxxx |Mime-Version:=201.0|Content-Transfer-Encoding:=207bit; bh=O+lXZtGYpqSrmIn7fnhInqo/SyQA30BTBSELRk78ETo=; b=gz49D7KXGtAV5ZV8UsTxyvvqLBKidQUNrEnwVQEoXYbAuHRWgj7uA403 fk3Ci5GOXlcwNWnLkA1ajB9+xaa5PcG8v575WACoQOmqyGYo1wHN1m2RX jjer8hNICI91BsqH30UptSvO/FguQK7DeBs5+q+MriNGO4bqCgrRogupV M=;
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=3095; t=1254343338; x=1255207338; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtroxell@xxxxxxxxx; z=From:=20Richard=20<rtroxell@xxxxxxxxx> |Subject:=20Extended=20attribute=20caching=20questions |Sender:=20; bh=O+lXZtGYpqSrmIn7fnhInqo/SyQA30BTBSELRk78ETo=; b=TK63kguSFmhOOtnc6ZNKyp61a3gbJL5sUAA7Rmz4Vf7QnxkIazVsFm7jXB lOifnxq+AxlxJKoHMpUrmccz5cPIZiqq8keX2vumO4/awqyVeAYveXBTzf62 gorTcgS8yu;
Hello All,

Terribly sorry for the long message. I have been digging for attribute
caching details everywhere, but cant seem to find any complete answers.

I am reading up on extended attributes, and see a great potential for
reducing the complexity of managing metadata associated with a file. The
approach I would be replacing uses a scheme where by meta files are
stored in the same directory as the data file with fixed tags appended
to the original file's name.


The idea, as expected, is to place the meta information beneath foo/bar,
with large attributes XXX and YYY. 

In my case, I have 2 - 3 meta file containing roughly 3k of packed data.
For simplicity / syscall overhead sakes it will be most conveinient for
me to simply stuff the existing formats within the attributes, treating
them like forks. I also need to account for potentially large volumes of
files (ex: 1 Million or greater) spread across the filesystem.

In this scenario (small attribute count, large attribute size), the
ideal solution would be to have a special short-form attribute type that
directly references a standalone extent(s); again, much like a file
fork. The benefit here, is that the single inode would be able to map
the data of 3 different files, resulting in a 3:1 reduction in I/O
lookup overhead and a 3:1 reduction of inode/dentry cache entries.

While this would be ideal for my particular case, my understanding is
that, in this scenario, XFS will create 'leaf attributes.' This is
understandable given the N/V interface of attributes, however, I get the
impression that the overall performance could be worse than the 3 file
approach, as the leaf block will place an additional I/O between the
inode and meta data.

Though the I/O seems to be higher in this scenario, the simplcity of the
attribute design might still outweigh the performance impact. Once more,
given a mostly-read scenario, the effective I/O overhead could be
greatly reduced depending on how the leaf block / attribute data are

In the typical 'file' scenario, dentries and inodes will be cached in
their respective VFS caches, and file data will be cached in association
with the inode's address space via the page cache. To my knowledge, none
of these caches gel with the concept of extended attributes, and thus,
if caching is happening, it would be up to the filesystem to implement

That said, here are my basic questions...

1) How are leaf blocks cached? What are the cached entries lifetimes,
and when will the cache shrink?

2) How will attribute data be cached, and what is its lifetime? Is there
a XFS-maintained equivalent of a page cache?

3) Does an extended attribute modification update the inode? This would
imply 3 updates for adding an attribute: inode, leaf block, data
block(s)... or more if the temporary state of leaf attribute while
allocating external blocks?

Also, I am happy to trace through the code, if someone can point me to
the respective functions / files.


<Prev in Thread] Current Thread [Next in Thread>
  • Extended attribute caching questions, Richard <=