Re: [Findutils-patches] [PATCH] Add a -sort option to use fts's sorted traversal functionality

[Phil Miller]

On Jan 6, 2015 10:14 AM, "Eric Blake" <address@hidden> wrote:
>
> On 01/05/2015 11:08 PM, Phil Miller wrote:
> > On Fri, Jan 2, 2015 at 7:48 PM, Eric Blake <address@hidden> wrote:
> >
> >> On 12/29/2014 04:49 PM, Phil Miller wrote:
> >>> * find/defs.h (struct options): Add a 'sort' flag.
> >>
> >> A boolean flag is insufficient.  The default should remain unsorted, but
> >> you should offer the ability to sort by either name or inode, which
> >> means -sort needs to take an argument to say which sorting method to use.
> >>
> >
> > The motivating use case for this patch is in enumerating files in a stable
> > order, from <https://bugs.debian.org/719845>. Sorting by inode doesn't
> > offer that benefit, since it will vary every time a given tree is
> > generated.
>
> Just because YOU don't plan to sort by inode does not rule it out as a
> useful sort.  Coruetils proved that it is MUCH faster to implement 'rm
> -r' when visiting a hierarchy sorted in inode order than it is in
> unsorted or name order - so there ARE operations where finding names in
> inode order will provide speedups to some clients.

Ok, that's the sort of motivating detail I was wondering about.

>
> > I can imagine a potential performance benefit to downstream
> > consumers in sorting by inode (putting subsequent disk access in roughly
> > consecutive order), but I don't see much payoff in implementing it without
> > some more concrete motivation.  That said, if it will smooth integration,
> > it's easy enough for me to just go ahead and implement.
>
> Gnulib's fts module already provides all three sort orders (unsorted,
> name, and inode), so it should be fairly easy to wire up all three
> (since we are already using unsorted by default).

I'll get this implemented shortly. Thanks for letting me know that FTS provides this - that'll let me drop the wrapper functions I would have written.