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