 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> 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
|
|
| |
| |
|
|
|
|
| |
|
|
