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

Le 2011-06-07 06:58, Invisible a écrit :
> 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

On 07/06/2011 02:45 PM, Darren New wrote:
> 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.

OK. So it's called a file allocation table rather than a directory 
listing. Same difference.

> 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. ;-)

Why would a security update break a program that only reads and writes 
text files and accesses the serial port?

Post a reply to this message

On 6/7/2011 7:04, Invisible wrote:
> 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?

And it has to be not completely corrupted if you remove it?

> Because it's a trivially easy optimisation?

Not really.  What happens if you have multiple processes writing to the disk 
at the same time?  You're looking at one specific use case, and complaining 
that the general tool isn't optimized for that use case.

-- 
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 7:05, Invisible wrote:
> OK. So do it in the opposite order. Write the directory entry last, after
> all the files have been written.

It's not the directory entry. It's the file allocation table.

-- 
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 7:08, Invisible wrote:
> OK. So it's called a file allocation table rather than a directory listing.
> Same difference.

Um, no. These are two entirely different things.

> Why would a security update break a program that only reads and writes text
> files and accesses the serial port?

Because the serial port is hardware that many programs accessed without 
going through the operating system to do so.

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

Post a reply to this message

>> Because it's a trivially easy optimisation?
>
> Not really. What happens if you have multiple processes writing to the
> disk at the same time? You're looking at one specific use case, and
> complaining that the general tool isn't optimized for that use case.

You know, the rest of the filesystem is cached too, and that doesn't 
seem to cause any problems...

Post a reply to this message

On 07/06/2011 03:36 PM, Darren New wrote:
> On 6/7/2011 7:08, Invisible wrote:
>> OK. So it's called a file allocation table rather than a directory
>> listing. Same difference.
>
> Um, no. These are two entirely different things.

In what way?

>> Why would a security update break a program that only reads and writes
>> text files and accesses the serial port?
>
> Because the serial port is hardware that many programs accessed without
> going through the operating system to do so.

Ah, now *that* I would expect to fail, yes. And, indeed, one of our 
other programs *does* fail on Windows XP because it actually tries to 
overwrite SERIAL.SYS with its own customised version...

Post a reply to this message

On 6/7/2011 7:49, Invisible wrote:
> You know, the rest of the filesystem is cached too,

Not on a removable floppy drive.

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

Post a reply to this message

Le 07/06/2011 16:50, Invisible a écrit :
> On 07/06/2011 03:36 PM, Darren New wrote:
>> On 6/7/2011 7:08, Invisible wrote:
>>> OK. So it's called a file allocation table rather than a directory
>>> listing. Same difference.
>>
>> Um, no. These are two entirely different things.
> 
> In what way?

The File allocation table is a MAP of sectors (which ones are free,
which ones are busy). When writing a file, not in that order:
 * allocate sectors for the file content
 * file the sectors with file content
 * update the sector of the directory content to have "name-->sector/id"
 * update the FAT.

Notice that until you update the FAT, you cannot have a concurrent
allocation for another file.
(also, the update of directory might need a new sector)



-- 
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

On 6/7/2011 7:50, Invisible wrote:
> On 07/06/2011 03:36 PM, Darren New wrote:
>> On 6/7/2011 7:08, Invisible wrote:
>>> OK. So it's called a file allocation table rather than a directory
>>> listing. Same difference.
>>
>> Um, no. These are two entirely different things.
>
> In what way?

http://en.wikipedia.org/wiki/FAT_file_system#Design

In the same way that a linked list is an entirely different thing from a 
hashtable.

> Ah, now *that* I would expect to fail, yes. And, indeed, one of our other
> programs *does* fail on Windows XP because it actually tries to overwrite
> SERIAL.SYS with its own customised version...

That's another example.

-- 
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 8:02, Le_Forgeron wrote:
> The File allocation table is a MAP of sectors (which ones are free,
> which ones are busy).

Actually, it's not only that but also what granules are allocated to what 
file in what order.  It's not just a free-space bitmap, but an actual 
collection of linked lists.

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

Post a reply to this message

>>>> OK. So it's called a file allocation table rather than a directory
>>>> listing. Same difference.
>>>
>>> Um, no. These are two entirely different things.
>>
>> In what way?
>
> http://en.wikipedia.org/wiki/FAT_file_system#Design

Oh, I see. So the FAT is just a map of free clusters?

I don't think that impacts what I originally said though; you could 
still cache it.

> In the same way that a linked list is an entirely different thing from a
> hashtable.

Conceptually, a dictionary is a dictionary, regardless of which data 
structure you use to implement it.

Post a reply to this message

On 6/7/2011 8:29, Invisible wrote:
> Oh, I see. So the FAT is just a map of free clusters?

No. It's a file allocation table.

> I don't think that impacts what I originally said though; you could still
> cache it.

It is cached. It's just that the cache gets written when you close a file 
after allocating space from the cache, because the system can't tell you're 
going to copy more files.  Otherwirse, writing a big file would have to 
slopping back and forth between three different tracks for every granule 
written.

>> In the same way that a linked list is an entirely different thing from a
>> hashtable.
>
> Conceptually, a dictionary is a dictionary, regardless of which data
> structure you use to implement it.

And a linked list is not a dictionary.

-- 
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 04:39 PM, Darren New wrote:
> On 6/7/2011 8:29, Invisible wrote:
>> Oh, I see. So the FAT is just a map of free clusters?
>
> No. It's a file allocation table.

That's like saying "an open set is any set that's open". This is a 
useless description.

>> I don't think that impacts what I originally said though; you could still
>> cache it.
>
> It is cached. It's just that the cache gets written when you close a
> file after allocating space from the cache, because the system can't
> tell you're going to copy more files. Otherwirse, writing a big file
> would have to slopping back and forth between three different tracks for
> every granule written.

OK. But I still don't see why you can't cache the entire disk image on a 
typical modern PC. (Obviously there was a time when this would have been 
impractical.)

Post a reply to this message

On 6/7/2011 8:41, Invisible wrote:
> On 07/06/2011 04:39 PM, Darren New wrote:
>> On 6/7/2011 8:29, Invisible wrote:
>>> Oh, I see. So the FAT is just a map of free clusters?
>>
>> No. It's a file allocation table.
>
> That's like saying "an open set is any set that's open". This is a useless
> description.

You're sitting in front of google. And wikipedia.

> OK. But I still don't see why you can't cache the entire disk image on a
> typical modern PC. (Obviously there was a time when this would have been
> impractical.)

You can. But if you want to make it safe to remove the disk when it's 
consistent, you still have to write it out after you make changes. I'm not 
sure why you're not getting this point.  Floppy disks don't have a "remove 
safely" feature. They have a hardware button on the front.

-- 
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 03:58 PM, Darren New wrote:
> On 6/7/2011 7:49, Invisible wrote:
>> You know, the rest of the filesystem is cached too,
>
> Not on a removable floppy drive.

So, essentially, your entire argument is "the user can eject the disk at 
any time, therefore it's unsafe to cache anything".

Correct me if I'm wrong, but wouldn't the contents of the disk be 
irrepairably corrupted *anyway*? That's why there's a disk activity 
light; so you don't hit eject while it's still writing stuff.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Tue, 07 Jun 2011 13:00:17 +0100, Invisible wrote:

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

Standard sizes are/were 3.5", 5.25", and 8".

Jim

Post a reply to this message

On Tue, 07 Jun 2011 18:13:05 +0100, Orchid XP v8 wrote:

> On 07/06/2011 03:58 PM, Darren New wrote:
>> On 6/7/2011 7:49, Invisible wrote:
>>> You know, the rest of the filesystem is cached too,
>>
>> Not on a removable floppy drive.
> 
> So, essentially, your entire argument is "the user can eject the disk at
> any time, therefore it's unsafe to cache anything".
> 
> Correct me if I'm wrong, but wouldn't the contents of the disk be
> irrepairably corrupted *anyway*? That's why there's a disk activity
> light; so you don't hit eject while it's still writing stuff.

Having actually done this at several points in the past, I can assure you 
that Darren is correct.  Caching removable devices tends to be *very* bad 
for data integrity.

That's why, for example, in Windows (and on Linux), you need to "safely 
remove" USB flash drives - they are cached for performance reasons.

Jim

Post a reply to this message

On 07/06/2011 06:21 PM, Jim Henderson wrote:

> Standard sizes are/were 3.5", 5.25", and 8".

Random fact: I'm ancient enough to *remember* 5.25" floppy disks. (They 
were noteable in that they were actually *floppy*.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> So, essentially, your entire argument is "the user can eject the disk at
>> any time, therefore it's unsafe to cache anything".
>>
>> Correct me if I'm wrong, but wouldn't the contents of the disk be
>> irrepairably corrupted *anyway*? That's why there's a disk activity
>> light; so you don't hit eject while it's still writing stuff.
>
> Having actually done this at several points in the past, I can assure you
> that Darren is correct.  Caching removable devices tends to be *very* bad
> for data integrity.
>
> That's why, for example, in Windows (and on Linux), you need to "safely
> remove" USB flash drives - they are cached for performance reasons.

In which way is suddenly removing a USB flash drive different from 
suddenly ejecting a floppy disk?

So why is it perfectly OK to cache a USB flash drive, but completely 
unthinkable to cache a floppy disk?

(Also, I'm sure I saw somewhere a setting in Windows to select whether 
the "safely remove hardware" thing is optional or not. The default 
setting is worse performance in exchange for pulling the drive /not/ 
completely screwing the filesystem. I'm guessing M$ found that too many 
people actually did this...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Tue, 07 Jun 2011 18:26:36 +0100, Orchid XP v8 wrote:

>>> So, essentially, your entire argument is "the user can eject the disk
>>> at any time, therefore it's unsafe to cache anything".
>>>
>>> Correct me if I'm wrong, but wouldn't the contents of the disk be
>>> irrepairably corrupted *anyway*? That's why there's a disk activity
>>> light; so you don't hit eject while it's still writing stuff.
>>
>> Having actually done this at several points in the past, I can assure
>> you that Darren is correct.  Caching removable devices tends to be
>> *very* bad for data integrity.
>>
>> That's why, for example, in Windows (and on Linux), you need to "safely
>> remove" USB flash drives - they are cached for performance reasons.
> 
> In which way is suddenly removing a USB flash drive different from
> suddenly ejecting a floppy disk?

Because people are used to ejecting a diskette when they've finished 
writing to it.  Sometimes you have to keep an old method around because 
of the habits people form.

> So why is it perfectly OK to cache a USB flash drive, but completely
> unthinkable to cache a floppy disk?

See above.

> (Also, I'm sure I saw somewhere a setting in Windows to select whether
> the "safely remove hardware" thing is optional or not. The default
> setting is worse performance in exchange for pulling the drive /not/
> completely screwing the filesystem. I'm guessing M$ found that too many
> people actually did this...)

Performance vs. reliability.  Traditional tradeoff.

Jim

Post a reply to this message

On Tue, 07 Jun 2011 18:24:32 +0100, Orchid XP v8 wrote:

> On 07/06/2011 06:21 PM, Jim Henderson wrote:
> 
>> Standard sizes are/were 3.5", 5.25", and 8".
> 
> Random fact: I'm ancient enough to *remember* 5.25" floppy disks. (They
> were noteable in that they were actually *floppy*.)

You do realise that 30 is *not* "ancient", right?

Jim

Post a reply to this message

>> Random fact: I'm ancient enough to *remember* 5.25" floppy disks. (They
>> were noteable in that they were actually *floppy*.)
>
> You do realise that 30 is *not* "ancient", right?

Are you kidding me? I was obsolete technology, like, 20 years ago...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> (Also, I'm sure I saw somewhere a setting in Windows to select whether
>> the "safely remove hardware" thing is optional or not. The default
>> setting is worse performance in exchange for pulling the drive /not/
>> completely screwing the filesystem. I'm guessing M$ found that too many
>> people actually did this...)
>
> Performance vs. reliability.  Traditional tradeoff.

Yes. That makes sense. Turn it on if you want more speed, turn if off if 
reliability is more important.

What doesn't really make sense is that for a floppy disk, there's no 
option to turn it on.

Still, hopefully I will never have to access a floppy disk again for the 
rest of my natural life, so it won't actually *matter* or anything...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 6/7/2011 10:13, Orchid XP v8 wrote:
> So, essentially, your entire argument is "the user can eject the disk at any
> time, therefore it's unsafe to cache anything".

No. It's unsafe to cache data structures that have interrelationships. It's 
unsafe to cache the data a pointer points to in RAM while writing the 
pointer back to disk.

The FAT *is* cached. It's just *also* flushed when you close each file.

How would you tell the machine it's time to write the cache to the floppy?

> Correct me if I'm wrong, but wouldn't the contents of the disk be
> irrepairably corrupted *anyway*?

No. That's the point. You write things in the order that makes the files not 
corrupted if you remove them. That's why if you chkdsk a floppy after 
writing files but not closing them, you get "CHKDSK.001" type files.

-- 
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 10:26, Orchid XP v8 wrote:
> In which way is suddenly removing a USB flash drive different from suddenly
> ejecting a floppy disk?

It's not. It'll screw up your USB drive also if you remove it without 
flushing the buffers.

> So why is it perfectly OK to cache a USB flash drive, but completely
> unthinkable to cache a floppy disk?

Because people have learned they can't just yank out a USB disk and think 
it'll be OK.  Whereas the old versions of DOS said "once you come back to 
the command prompt, it's safe to take out the disk."

> (Also, I'm sure I saw somewhere a setting in Windows to select whether the
> "safely remove hardware" thing is optional or not. The default setting is
> worse performance in exchange for pulling the drive /not/ completely
> screwing the filesystem. I'm guessing M$ found that too many people actually
> did this...)


There ya go.


-- 
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 10:40, Orchid XP v8 wrote:
> Still, hopefully I will never have to access a floppy disk again for the
> rest of my natural life, so it won't actually *matter* or anything...

Which is why MS isn't investing a whole ton of effort into optimizing this case.

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

Post a reply to this message

On Tue, 07 Jun 2011 18:40:04 +0100, Orchid XP v8 wrote:

>>> (Also, I'm sure I saw somewhere a setting in Windows to select whether
>>> the "safely remove hardware" thing is optional or not. The default
>>> setting is worse performance in exchange for pulling the drive /not/
>>> completely screwing the filesystem. I'm guessing M$ found that too
>>> many people actually did this...)
>>
>> Performance vs. reliability.  Traditional tradeoff.
> 
> Yes. That makes sense. Turn it on if you want more speed, turn if off if
> reliability is more important.
> 
> What doesn't really make sense is that for a floppy disk, there's no
> option to turn it on.

People form habits, and rather than deal with people saying "Hey, you 
never told me I would lose data by doing this" (no matter how many 
warnings there are, someone will claim that and will sue over lost data 
as a result), they decided to leave it alone.

> Still, hopefully I will never have to access a floppy disk again for the
> rest of my natural life, so it won't actually *matter* or anything...

I was a bit surprised about 6 weeks ago when I had to.

Jim

Post a reply to this message

On Tue, 07 Jun 2011 18:38:59 +0100, Orchid XP v8 wrote:

>>> Random fact: I'm ancient enough to *remember* 5.25" floppy disks.
>>> (They were noteable in that they were actually *floppy*.)
>>
>> You do realise that 30 is *not* "ancient", right?
> 
> Are you kidding me? I was obsolete technology, like, 20 years ago...

Pardon me while I go bang my head against a brick wall for 20 minutes.

I'm 40, so what does that make me?

You still learn (hell, you go out of your way to learn new stuff).  30 is 
nothing.  Talk to your grandparents if you think *you're* old.

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Tue, 07 Jun 2011 18:38:59 +0100, Orchid XP v8 wrote:
>
> >>> Random fact: I'm ancient enough to *remember* 5.25" floppy disks.
> >>> (They were noteable in that they were actually *floppy*.)
> >>
> >> You do realise that 30 is *not* "ancient", right?
> >
> > Are you kidding me? I was obsolete technology, like, 20 years ago...
>
> Pardon me while I go bang my head against a brick wall for 20 minutes.
>
> I'm 40, so what does that make me?

a relic? :p

Post a reply to this message

On Tue, 07 Jun 2011 18:01:43 -0400, nemesis wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Tue, 07 Jun 2011 18:38:59 +0100, Orchid XP v8 wrote:
>>
>> >>> Random fact: I'm ancient enough to *remember* 5.25" floppy disks.
>> >>> (They were noteable in that they were actually *floppy*.)
>> >>
>> >> You do realise that 30 is *not* "ancient", right?
>> >
>> > Are you kidding me? I was obsolete technology, like, 20 years ago...
>>
>> Pardon me while I go bang my head against a brick wall for 20 minutes.
>>
>> I'm 40, so what does that make me?
> 
> a relic? :p

LOL

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> In which way is suddenly removing a USB flash drive different from 
> suddenly ejecting a floppy disk?

  It's not, which is the point. If you remove a USB drive without flushing,
you will probably get data loss.

> So why is it perfectly OK to cache a USB flash drive, but completely 
> unthinkable to cache a floppy disk?

  Why should operating systems switch to a less safe method of writing to
floppy disks than in the past? And why even bother changing anything given
that floppy disks are a dead medium?

-- 
                                                          - Warp

Post a reply to this message

Le 2011-06-07 13:13, Orchid XP v8 a écrit :
> On 07/06/2011 03:58 PM, Darren New wrote:
>> On 6/7/2011 7:49, Invisible wrote:
>>> You know, the rest of the filesystem is cached too,
>>
>> Not on a removable floppy drive.
>
> So, essentially, your entire argument is "the user can eject the disk at
> any time, therefore it's unsafe to cache anything".
>
> Correct me if I'm wrong, but wouldn't the contents of the disk be
> irrepairably corrupted *anyway*? That's why there's a disk activity
> light; so you don't hit eject while it's still writing stuff.
>

Actually, no.  The activity light is to prevent you from physically 
damaging the RW head by pulling on the diskette while the head is still 
in harm's way.  5.25" and 8" drives actually locked the door while the 
head was moving.

-- 
/*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

Francois Labreque <fla### [at] videotronca> wrote:
> 5.25" and 8" drives actually locked the door while the 
> head was moving.

  Ah, the time when disks were actually physically pulled out of the drive
via manual force, rather than being ejected by a spring mechanism...

  Would you believe I'm too young to have ever used such disk drives?
I grew up with 3.5-inch hard-covered "floppy" disks. The luxury.

-- 
                                                          - Warp

Post a reply to this message

On 08/06/2011 02:38 PM, Warp wrote:
> Francois Labreque<fla### [at] videotronca>  wrote:
>> 5.25" and 8" drives actually locked the door while the
>> head was moving.
>
>    Ah, the time when disks were actually physically pulled out of the drive
> via manual force, rather than being ejected by a spring mechanism...
>
>    Would you believe I'm too young to have ever used such disk drives?
> I grew up with 3.5-inch hard-covered "floppy" disks. The luxury.

My memory is that on the 5.25" drive I saw, you turned a little knob 
(which blocks the slot where the disk goes in). Until you turn this 
knob, the drive won't acknowledge the media.

Let me see if I can find an image...

...there we go:

http://en.wikipedia.org/wiki/Commodore_1541

As you can see, with the knob turned, you physically can't move the 
disk, because the knob is in the way.

Post a reply to this message

On 6/8/2011 6:22, Francois Labreque wrote:
>  5.25" and 8" drives actually locked the door while the head was moving.

More precisely, on every model I saw, the door-open was a latch (i.e., 
something you turn like a doorknob or such rather than a push button), and 
the heads were attached to that. So moving the blocking bar out of the way 
of the drive slot also lifted the heads off the disk.

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

Post a reply to this message

On 6/8/2011 6:59, Invisible wrote:
> As you can see, with the knob turned, you physically can't move the disk,
> because the knob is in the way.

And the heads were attached to the knob, yes. (Or at least lifted when you 
turned it.)

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

Post a reply to this message

On 08/06/2011 06:44 PM, Darren New wrote:
> On 6/8/2011 6:59, Invisible wrote:
>> As you can see, with the knob turned, you physically can't move the disk,
>> because the knob is in the way.
>
> And the heads were attached to the knob, yes. (Or at least lifted when
> you turned it.)

Really? I didn't know that...

Post a reply to this message

Am 07.06.2011 12:58, schrieb Invisible:

> 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...

Keeping things as consistent as FAT allows at any one time, as a 
safeguard agains the user ejecting a disk during operation?

Post a reply to this message

On 6/7/2011 6:45 AM, Darren New wrote:
> 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. :-)
>
First off, for storage media, you don't want to do it that way in the 
bloody first place. You want to make sure the data is actually there 
*first*, so that when you point the file table to it, its not pointing 
at empty disk space. But, to do that, you have to go back to where the 
directory data is located, and update it to point at the now *actually 
there* data.

Personally, I never *quite* understood how you get more reliability, 
with something like storing what you are doing, so you can replay it, if 
the disk gets unmounted. You still need to have the shit you did *on* 
the disk, so you can replay it. Which means that the only thing you 
might be saving is some seek time, if you have your session data stored 
at the start of the disk, and the final write/replay goes to a bunch of 
different places. Its basically writing to a swap file, then using that 
to generate the data, if the power goes out. But, you have to write the 
data, then read it, then write it again, to finalize the changes. Sure 
it makes sense to someone, and works, but, unless you are storing that 
shit of flash ram, or something, then writing it out to slower media, 
you are doubling the amount of stuff you are doing, probably wearing out 
the disk faster, since you are rewriting your transaction record to the 
same swap area over and over, and so on. The whole, "write once, update 
the table saying where the data is, and you are done", seems to me to 
make a lot of damn sense, if you want to be *sure* it gets written. All 
the rest is done for speed, not reliability. So.. Which is more 
important to you, actually having the data, when you need it, or being 
able to load/change it very very fast? You don't get to have both.

Post a reply to this message

On 6/9/2011 12:36, Patrick Elliott wrote:
> But, to do that, you have to go back to where the directory data is
> located, and update it to point at the now *actually there* data.

This is FAT. The directory data only points to the first granule. You have 
to go back to the file allocation table for anything else. Which is exactly 
why it's slow when you have lots of small files.

> Personally, I never *quite* understood how you get more reliability, with
> something like storing what you are doing, so you can replay it, if the disk
> gets unmounted.

The reliability comes from the fact that you're basically keeping both 
copies around until you finish, and marking it as "finished" is atomic.

So you write a file. You have to update the directory, the allocation map 
for what blocks the file occupied, and you have to clear the bits out of the 
bitmap that says those blocks are free. Those three items might be in three 
different places on the disk.  What happens if you record where the file is 
stored, then mark those as used in the bitmap, and someone pulls out the 
disk between those two steps?

With a journal, you'd record those two operations in the journal, then you'd 
perform those two operations, then you'd record in the journal that you 
completed them. Anything missing that last step gets rolled back, just like 
in any other database system.

> You still need to have the shit you did *on* the disk, so
> you can replay it.

Right. But you don't overwrite the old version until *all* parts of the new 
version are recorded. Just like in a database transaction, you don't 
overwrite the balance of the account you're taking money out of before 
you're recorded that you want to put money into the other account.

You basically wind up recording your intention, then executing your 
intention, then recording that you've finished executing your intention. The 
journal isn't really for efficiency as much as it is for reliability.

Of course, in this particular case, it serves as both, specifically 
*because* you wind up being able to stage storing a bunch of files, *then* 
doing a bunch of updates to areas of the disk that are far apart.

 > "write once, update the table saying where the data is, and you are
> done", seems to me to make a lot of damn sense,

That's how a lot of systems work, except you still eventually need to get 
rid of the old stuff.

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

Post a reply to this message