[TAG] [Fwd: RW "Quick Format"...]

Brian Bilbrey bilbrey at orbdesigns.com
Mon Mar 7 00:19:39 MSK 2005


Here's a reply to my posting of the Packet Writing material on my own
site. I've gotten his permission to forward this into TAG as commentary
on the original, so if you want to use it... ?


best,

.brian




-------- Original Message --------
Subject: RW "Quick Format"...
Date: Sun, 6 Mar 2005 13:36:24 -0500
From: David Yerka <leshaworks at iname.com>
To: TAG <tag at lists.linuxgazette.net>
To: <bilbrey at orbdesigns.com>

Hi Brian,

Actually the time for UDF formatting of a CDRW is consistant with Nero's
packet driver (InCD) under Windows. InCD used to have multiple selections of
"Format" and "Quick Format" available but only the "Format" option was
available for a BLANK CDRW disk and formatting could take up to 45min to an
hour. A previous formatted UDF disk would let you "quick format" and take
considerably less time; some times as short as 6min.

Of course, I suspect the "quick format" is really only doing a quick erase
and random verify of the file system. This would be similar to a 'quick
erase' of a CDRW disk which was written/formatted as an iso -- erase the
header and directory structure but don't bother with rest of data (i.e. lets
hope the surface, etc. is OK and we'll just overwrite for the new
compilation).

I had a Mount Ranier capable CDRW drive at one point and I noticed that it
worked a bit differently. Apparently MR drives can format and write "at the
same time" and also do formatting in the background. So, when using MR
(instead of UDF 1.5) it appeared only the disk headers and directory
structure was initially formatted. Then, as data was sent to the drive (by
"drag and drop" or whatever) it was cached and buffered, then the space
needed was formatted and written to in the background. When the disk was
ejected a significate delay occured while anything left in the cache was
written out to disk and the disk cleaned up. It appeared that only as much
of the disk was actually formatted as needed because you could "force" a
full disk format in MR and it would take about as long to complete as a
format as UDF.

Users should also be aware that UDF file systems are much, much less safe
than standard iso compilations. They are more effected by heat. Not all UDF
file systems are equal -- especially now that various revision levels are
out (UDF1.5 appears to be "standard recommended" while there were revisions
up to 2.5 last time I looked). In practice I've found that using packet
writting is tends to work only for the computer/drive you write it on and
only for relatively short term storage.
 Note the fact that Windows XP's setup for CD writing uses a disk buffer and
writes only a iso. It simulates a "drag and drop" random access file system
by mapping the CDRW disk to the buffer (actually a system folder called "cd
burning") and then just burns asks to burn a standard iso. For adding to a
written disk it appear to load what is already on disk to the buffer adding
to the new files then erase the CDRW disk and re-burn it. I suspect even
good old Microsoft figured the odds of including UDF packed writing would be
adding another can of worms to XP.

David Yerka

PS: I have been testing Xandros OC 3.0.1 and I find I like it quite a bit. I
didn't find 2/2.5 really ready for an average business user but Xandros 3
looks to be a true MS desktop killer. A number of my clients are fed up with
paying through the nose for Windows "upgrades" -- some really feel MS
tugging the chain -- so they are very interested. I even have one office
where the practice management application will run under Crossover Office --
and the developers have decided to commit to a Linux version for release
next year.




-- 
Brian Bilbrey : http://www.orbdesigns.com/
	"Kirk to Enterprise -- beam down yeoman Rand and a six-pack."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3244 bytes
Desc: not available
Url : http://lists.linuxgazette.net/mailman/private/tag/attachments/20050306/f7c760cb/attachment-0001.bin 



More information about the TAG mailing list