Jim, Eric, list,
I have to say, the new getattrlistbulk() function is working very well
here. Requiring ATTR_CMN_RETURNED_ATTRS made me reorganize my code a
bit, but that was minor. Specifically, it's nice to have a single
routine to call (instead of getdirentriesattr() and a readdir() fallback
when it's not available). It's nice to have a less complicated use
pattern (i.e. no count-estimate/returned-count or state
management/reread code to write). And, I can confirm that's it's fast. :)
James
Jim Luther <mailto:luthe...@apple.com>
January 12, 2015 at 9:33 AM
getattrlistbulk() works on all file systems. If the file system
supports bulk enumeration natively, great! If it does not, then the
kernel code takes care of it. In addition, getattrlistbulk() supports
all non-volume attributes (getattrlistbulk only supported a large subset).
The API calling convention for getattrlistbulk() is slightly different
than getattrlistbulk() — read the man page carefully. In particular:
• ATTR_CMN_NAME and ATTR_CMN_RETURNED_ATTRS are required (requiring
ATTR_CMN_NAME allowed us to get rid of the newState argument).
• A new attribute, ATTR_CMN_ERROR, can be requested to detect error
conditions for a specific directory entry.
• The method for determining when enumeration is complete is
different. You just keep calling getattrlistbulk() until 0 entries are
returned.
- Jim
James Bucanek <mailto:subscri...@gloaming.com>
January 11, 2015 at 10:31 PM
Eric,
I would just like to clarify: the new getattrlistbulk() function works
on all filesystem. We don't have to check the volume's
VOL_CAP_INT_READDIRATTR capability before calling it, correct?
James Bucanek
Eric Tamura <mailto:etam...@apple.com>
December 10, 2014 at 5:57 PM
It should be much faster.
Also note that as of Yosemite, we have added a new API:
getattrlistbulk(2), which is like getdirentriesattr(), but supported
in VFS for all filesystems. getdirentriesattr() is now deprecated.
The main advantage of the bulk call is that we can return results in
most cases without having to create a vnode in-kernel, which saves on
I/O: HFS+ on-disk layout is such that all of the directory entries in
a given directory are clustered together and we can get multiple
directory entries from the same cached on-disk blocks.
How big are the directories in question? How many times are you
calling this?
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/subscriber%40gloaming.com
This email sent to subscri...@gloaming.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
