On May 24, 2012, at 6:19 PM, Bruce Dubbs wrote:

>> Overall, I think the results would be more robust if you could run
>> the same test with ext3 with the same mount options, and see what
>> those results are.
> 
> I created a new ext4 partition and mounted it noatime.  My rsync build 
> time was 20.3 seconds -- basically the same as ext3 with default mount 
> options.

Interesting.  And unlike my experience...I barely observed more than
a 10 minute speedup over an entire automated build (using LFS, and then
building enough of BLFS to support Xen)--which took about 3 to 4 hours.

On my SSD test machine, my processor & memory weren't great.  i5-2400
with pretty tame memory.  Are yours much faster?  I wonder if my stuff
was system made the build CPU-bound...

Where does LFS stand now with respect to building with noatime?
I thought I read in 7.0 that that was bad news (I remember something
being atime-sensitive, and breaking; maybe it was the glibc or
coreutils test suite...)

> For things like /bin and /usr, I wouldn't be particularly concerned 
> about atime and journaling since there is little or no writing (except 
> when doing the install part of a build).

I do agree that journaling is a whole other beast; i.e., if
we treat /usr and /bin as read-only (as a simplifying assumption)
then journaling should be entirely unnecessary, once they are created.

But...I think you may be missing the benefit of noatime.  The
purpose is to prevent write I/O when you just read files, by having
to update the inode on an open(2).  In fact, /usr should see the most
gain from noatime, because header files probably dumped from the
cache more often than, say, bash or gcc pages.

On a relatively complex operation like CMMI, which involves reading
hundreds (if not thousands) of files (package files, system includes,
system libraries, etc), I would expect noatime to have a pretty
significant difference.

Based on what you observed, I would bet that your ext3 partition
was mounted with relatime as the kernel default.  If that were the
case, you'd already be benefitting from read-side noatime.  And,
even though relatime doesn't exclude write-side atime, my guess
is that very few files are opened for writing more than once
(i.e., on creation), where recording atime would have practically
no impact.

You can test this by mounting the ext3 partition explicitly with
atime, then noatime, then with relatime (if you continue to be
interested in this).  :)

        Q



-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to