Question: How long does it take to copy 1.0 MB of data onto a 3" floppy 
disk?

Answer: I gave up after waiting about 25 minutes.



Of course, actually formatting the whole disk only takes about 30 
seconds, so there's no way copying the data to it should take that long. 
Is there?

Well, in this instance, there is. You see, for whatever reason, there's 
an issue with putting many small files onto such a disk. I don't know 
whether the issue is with the file system design or just the OS 
implementation, but it appears that every file creation operation 
involves writing the file's data to one block, and updating the file 
listing in another block. The result is that if you create many hundred 
tiny files, the [extremely slow] R/W heads spend forever repeatedly 
tracking back and forth, once per file. In this instance, copy time is 
proportional to the /number/ of files, not their /size/.

Quite why Windows can't just write the final listing to the directory 
block and then write all the file data blocks sequentially is beyond me, 
but anyway...

Fortunately, copying said files /off/ the disk again is slightly 
quicker. But only slightly.



But why do I know all this? I'll tell you why. Last week one of the 
ancient PCs in our lab stopped working. As in, you turn it on, all the 
lights come on, all the fans spin... and nothing else happens. The 
lights are on, but nobody's home.

Now, the PC was pretty damned warm. I came back the next day and it 
suddenly decided to work again. But each time it works for a while and 
then stops working once it gets warm. I removed several throw rugs' 
worth of dust, hair and fluff from the inside of the thing, but it's 
still not working reliably.

I suppose I could try to repair it. But... are you kidding me? Let's 
look at the spec sheet here:

Motherboard: Gigabyte GA-5AX
Processor: AMD K6 II with 3DNow!, 500 MHz
Memory: 128MB DDR1
Harddrive: 4.2 GB PATA
Graphics: S3 Trio3D/2X APG
Sound: None
Optical drive: None
Network: SMC 1211TX

Can you see why the inside might be a little dusty? Still, we only use 
this thing to run an old 16-bit Windows 3 program that controls some 
gear via a serial port. (Astonishingly, this works with Windows XP. Go 
figure...)

Anyway, at one time /all/ our PCs were to this exact spec. We bought a 
big batch of them so they would all be identical. Nice idea, but that 
was a few years ago now. (!) So I had a hunt around, and managed to find 
an 800 MHz Intel Celeron brick. So I installed the software on that, 
managed to get the failing PC to work for long enough to upload all the 
configuration files to a network share, unplugged the failing PC, moved 
the replacement into place, and...

...now the integrated NIC on the replacement PC doesn't work. No reason. 
It just doesn't. No matter how much I poke and prod it, I can't get any 
activity lights out of it. Not interested. Won't work.

Both PCs had perfectly OK network access before I started (as evidenced 
by the many network operations performed just prior to the move). If I 
unplug the network cable and plug it into any other device, it works. 
But it *refuses* to work when plugged into the replacement PC. For no 
reason other than to spite me.

Needless to say, I was extremely angry by the time I went home yesterday...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Question: How long does it take to copy 1.0 MB of data onto a 3" floppy 
> disk?

  Don't you mean a 3.5-inch floppy disk? I think 3-inch floppy disks
existed at some point, but they were really rare.

> Well, in this instance, there is. You see, for whatever reason, there's 
> an issue with putting many small files onto such a disk. I don't know 
> whether the issue is with the file system design or just the OS 
> implementation, but it appears that every file creation operation 
> involves writing the file's data to one block, and updating the file 
> listing in another block. The result is that if you create many hundred 
> tiny files, the [extremely slow] R/W heads spend forever repeatedly 
> tracking back and forth, once per file. In this instance, copy time is 
> proportional to the /number/ of files, not their /size/.

  That's how FAT works.

-- 
                                                          - Warp

Post a reply to this message

On 07/06/2011 12:34 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Question: How long does it take to copy 1.0 MB of data onto a 3" floppy
>> disk?
>
>    Don't you mean a 3.5-inch floppy disk?

I can never remember whether it's 3.5 or 3.25 inch.

>> I don't know
>> whether the issue is with the file system design or just the OS
>> implementation, but it appears that every file creation operation
>> involves writing the file's data to one block, and updating the file
>> listing in another block.

>    That's how FAT works.

Probably.

Still, why it can't build an image of what the final disk layout will 
look like in RAM and then write it all to disk in the most efficient 
order, I don't know. That's how I would probably do it.

(I guess Windows NT doesn't do this because when that was new, 64 MB RAM 
was considered "large". So using over 1.5% of it for the disk image was 
probably unacceptable. Why Windows XP still has this limitation is 
another matter...)

In the end, the resolution was to create a self-extracting archive of 
all the tiny files using 7zip. Remarkably, the resulting self-extracting 
file /actually works/ on Windows NT still. (As a happy side-effect, the 
1MB of data becomes 202KB.)

Post a reply to this message

Le 07/06/2011 14:00, Invisible a écrit :
> I can never remember whether it's 3.5 or 3.25 inch.

it's 3 & 1/2, and before 5 & 1/4.
just remember that the denominator is 1 less than the number of inches.

That's for PC. (and it does not work for 8" floppy... you do not want to
remember them!)

(3" did exist and were common on Amstrad... 3" is the width, as their
length was longer)

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

> Question: How long does it take to copy 1.0 MB of data onto a 3" floppy
> disk?
>
> Answer: I gave up after waiting about 25 minutes.
>
>
>
> Of course, actually formatting the whole disk only takes about 30
> seconds, so there's no way copying the data to it should take that long.
> Is there?
>
> Well, in this instance, there is. You see, for whatever reason, there's
> an issue with putting many small files onto such a disk. I don't know
> whether the issue is with the file system design or just the OS
> implementation,

It's FAT's fault.  This has nothing to do with the OS.

> but it appears that every file creation operation
> involves writing the file's data to one block, and updating the file
> listing in another block. The result is that if you create many hundred
> tiny files, the [extremely slow] R/W heads spend forever repeatedly
> tracking back and forth, once per file. In this instance, copy time is
> proportional to the /number/ of files, not their /size/.
>
> Quite why Windows can't just write the final listing to the directory
> block and then write all the file data blocks sequentially is beyond me,
> but anyway...

What happens if the power goes out in the middle of the operation and 
the file allocation table has already been written, but the actual data 
has not been copied over?  This is why you have to update the FAT 
everytime you use a block, and the directory everytime you write a file.

This is one of the earlier forms of transaction tracking.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 6/7/2011 3:58, Invisible wrote:
> Quite why Windows can't just write the final listing to the directory block
> and then write all the file data blocks sequentially is beyond me, but
> anyway...

Read up on how FAT works. It's not seeking back to write the directory 
listing. It's seeking back to read/write the FAT table.

Given modern memory sizes, it ought to be able to cache the FAT table, 
especially given that one might very reasonably be having only one process 
with files on the disk open to start with. But I suspect not a whole lot of 
time was put into optimizing that.

Blame UNIX.  The CP/M operators were much faster.  :-)

> Can you see why the inside might be a little dusty? Still, we only use this
> thing to run an old 16-bit Windows 3 program that controls some gear via a
> serial port. (Astonishingly, this works with Windows XP. Go figure...)

Didn't you just say that security updates can be done without breaking 
things? Yet here you are, amazed that a Win3 program runs under XP. ;-)

> Needless to say, I was extremely angry by the time I went home yesterday...

I need to learn how to not get frustrated by such things myself.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/7/2011 5:00, Invisible wrote:
> Still, why it can't build an image of what the final disk layout will look
> like in RAM and then write it all to disk in the most efficient order, I
> don't know. That's how I would probably do it.

It's a removable disk.

There were backup programs under DOS that worked this way, incidentally. 
You'd just page floppies and it would write them as fast as it could, even 
alternating drives. But when it was done, they were all valid files.

> (I guess Windows NT doesn't do this because when that was new, 64 MB RAM was
> considered "large". So using over 1.5% of it for the disk image was probably
> unacceptable. Why Windows XP still has this limitation is another matter...)

Why would you optimize something as slow as floppy access instead of 
improving other parts of the system to start with?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/7/2011 6:39, Francois Labreque wrote:
> This is why you have to update the FAT everytime you use a
> block, and the directory everytime you write a file.

Technically, you only need to update the FAT when you close the file. If you 
haven't recorded the length of the file, you don't really care if the space 
is marked as used in the FAT.

I.e., if you create a zero-length file name in the directory, then start 
writing the file, modifying a cached version of the FAT as you write, and 
then the power goes out (or the disk gets pulled), then the FAT says the 
space is unallocated and the directory says the file is unallocated, so 
you're OK.

So I think (IIRC) it writes the zero-length file to the directory, then 
reads the FAT, then writes the file data while updating the FAT sector, then 
finishes by flushing the final changes to the FAT and then going back to 
update the directory to point to the first block in the chain.

It also flushes the FAT sector whenever it moves to allocating from a 
different FAT sector, which is why you'll hear it write a few tracks, then 
crank back and forth, then write a few more tracks, then crank back and 
forth, as you copy a large file.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 07/06/2011 02:47 PM, Darren New wrote:
> On 6/7/2011 5:00, Invisible wrote:
>> Still, why it can't build an image of what the final disk layout will
>> look
>> like in RAM and then write it all to disk in the most efficient order, I
>> don't know. That's how I would probably do it.
>
> It's a removable disk.

And?

> There were backup programs under DOS that worked this way, incidentally.
> You'd just page floppies and it would write them as fast as it could,
> even alternating drives. But when it was done, they were all valid files.

Yeah. That seems like the most sensible way to go.

> Why would you optimize something as slow as floppy access instead of
> improving other parts of the system to start with?

Because it's a trivially easy optimisation?

Post a reply to this message

>> Quite why Windows can't just write the final listing to the directory
>> block and then write all the file data blocks sequentially is beyond me,
>> but anyway...
>
> What happens if the power goes out in the middle of the operation and
> the file allocation table has already been written, but the actual data
> has not been copied over? This is why you have to update the FAT
> everytime you use a block, and the directory everytime you write a file.
>
> This is one of the earlier forms of transaction tracking.

OK. So do it in the opposite order. Write the directory entry last, 
after all the files have been written.

It's not like anybody expects a floppy disk to actually operate 
*reliably*...

Post a reply to this message