From: dizzy <dizzy@roedu.net>
To: xfs@oss.sgi.com
Subject: Re: readdir() ordering guarantees on XFS
Date: Tue, 10 Jun 2008 11:20:27 +0300 [thread overview]
Message-ID: <200806101120.27473.dizzy@roedu.net> (raw)
In-Reply-To: <20080610035547.GZ10720@disturbed>
On Tuesday 10 June 2008 06:55:47 Dave Chinner wrote:
> On Fri, Jun 06, 2008 at 04:34:13PM +0300, dizzy wrote:
> > Hello
> >
> > POSIX leaves unspecified the order of getting the entries with readdir().
> > This is normal since different filesystems may implement their own
> > techniques to organize entries in a directory (linear, hash, various
> > search trees, etc).
> >
> > But if I can makes sure that several Linux machines will have the same FS
> > (ie XFS), mount options and same kernels can assume that traversing the
> > same file hierarchy structure (that is a file structure with the exact
> > same directories and files as names, structure, attributes, except maybe
> > "ctime" which we can't really control in Linux) can I expect that
> > traversing using readdir() will give me the entries in the exact same
> > order?
>
> No. For speed I suggest sorting the inode stat() calls in ascending
> inode number order before issuing them.
But this does not solve the main requirement, that is the files traversed on
the multiple Linux machines have to be sent in the same order (not sure if I
have specified this in the original mesage, sorry if not). For now I'm
sorting them lexicographically which is pretty slow. Sorting them by inode
would not give them in the same order.
> Also, perhaps you should
> look at:
>
> http://oss.oracle.com/~mason/acp/
>
> To see if you can use similar techniques to speed directory
> traversal.
Funny that you mention acp. We have benchmarked simple "tar" reading and "acp"
reading of directory structures and on XFS "tar" reading is faster (but not
on ext3), here are some results (reading a linux kernel tree after a flush of
the cache by "tar"-ing a huge ammount of data, double the memory size):
- xfs: acp: 1m32s, tar: 1m12s
- ext3: acp: 0m1.5s, tar: 0m2.8s
Although in the test ext3 seems to be much faster than XFS overall in reading,
it isn't so in writing so we will stick with XFS as it's fast enough for
reading and fast for writing. Anyway that is another topic.
We still have that ordering issues tho from the original message :)
--
Mihai RUSU Email: dizzy@roedu.net
"Linux is obsolete" -- AST
prev parent reply other threads:[~2008-06-10 8:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-06 13:34 readdir() ordering guarantees on XFS dizzy
2008-06-10 3:55 ` Dave Chinner
2008-06-10 8:20 ` dizzy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200806101120.27473.dizzy@roedu.net \
--to=dizzy@roedu.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox