20 Feb
2005
20 Feb
'05
10:09 p.m.
Patrick Useldinger a écrit :
Brent Frère wrote:
To optimise the head movements, you must drop the abstraction level of
the filesystem: you consider that it is implemented on a hard disk... In
this case, it would be efficient to process the files in the order of
physical block allocation... Not easy, and file-system dependant... Do
we really need this ?
To check a freshly brewed CD, I usually run this:
find /media/cdrom -type f -exec tail -1c {} \; > /dev/null && eject cdrom
It's incredibly efficient, even on slow CD readers, compared to a full
read. But it cause also some head movements...
If the CD is ejected, it is OK.
--
Brent Frère
Private e-mail: Brent(a)BFrere.net
Postal address: 5, rue de Mamer
L-8280 Kehlen
Grand-Duchy of Luxembourg
European Union
Mobile: +352-021/29.05.98
Fax: +352-26.30.05.96
Home: +352-307.341
URL: http://BFrere.net
If you have problem with my digital signature, please install the appropriate authority
certificate by browsing https://www.cacert.org/certs/root.crt.
Could you please urgently add this comment, as
otherwise this piece
of code could be stolen by some proprietary software company ?
OK, I've done it, as well as added a few optimisations - please have a
look if it's OK like that. But isn't refering to the GPL enough, as I
did it initially?
When I run the program over my disk which has a large number of
duplicates (especially on the windows partition), the head is spinning
quite heavily. I've increased the size of blocks it reads to keep the
movements down, but it's still impressive. Maybe calculating an MD5
would indeed speed up, i.e. have more reads but less head movement?
That is provided that files are more or less sequentially on a disk.
Maybe I'll make it an option, just to compare.
-pu