On Mon, 2008-12-08 at 18:55 +1100, Amos Shapira wrote: > 2008/12/8 William L. Maltby <CentOS4Bill at triad.rr.com>: > <snip> > > can/does. I guess I'll have to read up on cp some more and see if it > > leaves the access times alone (cpio parameter allows retaining that) and > > handles hard-links efficiently. > > I'm not sure why you should care about atime so much - more and more > people around (including Linus Torvalds) recommend to get rid of it > altogether. Ubunut comes with "relatime" as a default config already. Atime seems to have utility for determining when items may be candidates for removal due to lack of interest (if it is not updated by utilities such as backup processes). I suppose some security activities might make use of it in forensic processes? How about profiling FS activities? Other than those (rather inconsequential?) items, not much use. In reality, being raised on real UNIX(TM) systems from long ago and far away, it was just one of the things we wanted left unchanged when we did backups or shipped tapes to the outside world (one of my many jobs back then). There is the possibility that atime was tracked "because we can". But with performance being what it was back then, profiling for performance tuning seems the most likely supportable reason for having it. Keep in mind that tools such as SAR didn't exist initially. On my systems back then, I would order directories and files with a mix of access times, update profiles, etc. to achieve unexpected performance. Combined with FS tunables, one could support a lot more users than expected on an old 386/486/586 systems with _teeny_ amounts of memory. Never attempted multi-user on 286 systems. I think it would have been a waste of effort. > <snip> > --Amos > <snip sig stuff> -- Bill