[fdutils] format_n_write for faster disk-from-image creation?
Julien Plissonneau Duquene
jpd at junk.org
Tue Jul 22 08:44:21 CEST 2003
On Mon, Jul 21, 2003 at 09:51:02AM -0400, Charles R. Anderson wrote:
> format_track currently uses the FD_FORMAT FDRAWCMD. I'd probably
> start by copying this function to a new one format_track_with_data
> and modify that to use the FDRAWCMD FD_FORMAT_N_WRITE, which takes a
> sector of data as an additional parameter. No additional kernel
> support should be needed, so the utility should remain portable
> across Linux kernels.
OK, I thought it used FDFMTTRK.
> jpd> - verifying while being on the same track (faster) and using raw cmds
> jpd> (avoids read-ahead, track changes, retries on errors, *way* faster)
> jpd> - write patterns & verify before writing+verifying actual data, also
> jpd> using raw cmds, and optionnaly immediately discarding bad disks.
> I was thinking of using MD5 to compare the input file to the data
> written. This could be done for each track-sized chunk of data,
> either during or after formatting, just like the --verify-later
> option does. This would bring yet another advantage to a utility
> like this, since currently one has to format/verify, then dd, then
> verify the data with dd/diff/md5sum, all separately.
> I don't know about you, but I am sick of making Linux boot disks
> that fail to boot because they failed to write properly, even after
> passing the format verify.
Bad disks make through the format verify because the verify step is done
using standard read and writes (it seems), and the kernel will do
several retries when there is an error - without having a mean to tell
the format/verify utility that there were retries. The other
disadvantage of this is that the read-ahead feature mixes very badly
with bad sectors :
sectors being verified
/ bad sectors
=========... (length of read ahead)
In this example, if one dash means a track and the verify is track by
track, the kernel will still attempt to read several tracks ahead, and
block on bad sectors at every track read. They will not fail (as long as
you do not ask for the bad tracks), but they will be dog slow and
painfully noisy. The same problem arises for CDs and HDDs.
So I would also implement the verify step with raw commands, because it
seems to be the only reliable way to avoid retries and read-ahead : more
reliable AND faster.
In my experience there is no difference between formatting, writing &
verifying patterns, writing & verifying data in one pass (not changing
tracks between steps) or with recalibration between steps -- excepted
when it comes to bad drives/controllers.
I hope this helps ...
Julien Plissonneau Duquène.
fdutils mailing list
fdutils at tux.org
More information about the Fdutils