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