From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3203 invoked by alias); 28 Apr 2015 15:15:57 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34984 Received: (qmail 13888 invoked from network); 28 Apr 2015 15:15:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no version=3.3.2 Date: Tue, 28 Apr 2015 17:06:34 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: Filename generation: sorting by inode number Message-ID: <20150428150634.GA4973@ypig.lip.ens-lyon.fr> Mail-Followup-To: zsh-workers@zsh.org References: <20150425001719.GA12262@xvii.vinc17.org> <150424180109.ZM29158@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <150424180109.ZM29158@torch.brasslantern.com> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.23-6425-vl-r76280 (2015-03-04) On 2015-04-24 18:01:09 -0700, Bart Schaefer wrote: > On Apr 25, 2:17am, Vincent Lefevre wrote: > } Subject: Filename generation: sorting by inode number > } > } With the "o" glob qualifier for filename generation, it is not possible > } to sort by inode number. Such a feature could be very useful to speed up > } file reading on an ext3 file system when the files are not in the cache. > > Hrm. Does the inode ordering also affect stat() times? I've just done a test, and stat() in directory order is very fast on ext3. I think that the reason is that inode information is grouped at some specific place on the partition, and in a compact way I assume, so that there are few blocks to read. > This sounds less like something to expose as a sort ordering for the o/O > qualifiers and more like something to hide under the covers, e.g., so > that "oN" (unsorted) actually produces order by inode, instead of the > apparently pseudo-random order of readdir(). I don't know. Perhaps unsorted (= directory order) may have an advantage in some contexts (for some file systems). > How close does "oc" get you to this? It's difficult to say in practice. But in my case, many files are often created on the same second (due to copies by block of files). If the ctime resolution is the second, I fear that this won't solve the problem. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)