Qrux wrote: > 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... Mine is Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz I have 3G of RAM. > 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...) It does say that in Section 2.4 for /mnt/lfs but I don't remember why. I went back and searched the archives and see something about the glibc tests from 2003. >> 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. I agree. > 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. Depends too on disk caching. > 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). :) No, I think I'm about spent on this issue for now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
