Very Computer

I have a floppy formatting/testing script.  In order to verify that
written data is correct, I have to manually eject the floppy and
reinsert it to "dirty" the Unix buffers.

Is there a way to "dirty" the IO buffers from my script?

Quote:> I have a floppy formatting/testing script.  In order to verify that
> written data is correct, I have to manually eject the floppy and
> reinsert it to "dirty" the Unix buffers.

> Is there a way to "dirty" the IO buffers from my script?

If you unmount the filesystem, everything is flushed to the media
at that point.  You can do the same thing with sync, except that
it might complete asyncronously so your script can't assume the
operation is complete just because the sync command finished.

When I need to "verify" a removable medium like a floppy or a tape,
I usually just dd it from the raw device into /dev/null.  The dd
will moan if there are media errors and your script can check for
status reliably.  You can also look at the dd output to see how
many blocks of what sizes were read and how fast, if you need a
more sophisticated view of how well the medium can be read.

Reads to the raw device (/dev/rfd0) ALWAYS translate into physical
reads.  There is no buffering.  Only filesystem I/O going on via
the kernel's filesystem implementation is buffered.  I recall that
FreeBSD has dropped the old block-device semantics and even block
(cooked) devices work like raw devices when userland processes try
to use them.

============================================================

Ottawa, ON             FreeBSD: Where you want to go. Today.

But I never have the thing mounted. I"m writing 1's and 0's, reading
them back, writing 0's and 1', reading them back.  Writing with
">" which I think waits for completion.  In any case, that's not my
problem.  The problem is that if I read the data back off the floppy
then the OS reads from a buffer, not from the floppy.  At least that's
how I understood it to work (and think I remeber observing) on Linux
where I wrote the first version of the script.  More below.

Quote:> When I need to "verify" a removable medium like a floppy or a tape,
> I usually just dd it from the raw device into /dev/null.  The dd
> will moan if there are media errors and your script can check for
> status reliably.  You can also look at the dd output to see how
> many blocks of what sizes were read and how fast, if you need a
> more sophisticated view of how well the medium can be read.

I think that only detects errors in the floppy formatting.  I'm
letting the "fdformat" command (with verification) handle that part.
I don't know if that even touches the data bytes.  I'd be nice to
know what it does.

Quote:> Reads to the raw device (/dev/rfd0) ALWAYS translate into physical
> reads.  There is no buffering.  Only filesystem I/O going on via
> the kernel's filesystem implementation is buffered.  I recall that
> FreeBSD has dropped the old block-device semantics and even block
> (cooked) devices work like raw devices when userland processes try
> to use them.

Now THAT's interesting.  Sounds like the buffers don't exist and so
don't need to be dirtied on FreeBSD.  Guess I should try some
experiments and try to verify that for my own satisfaction.  I must
admit to not experimenting with my FreeBSD version.

Thanks much.

Quote:

> But I never have the thing mounted. I"m writing 1's and 0's, reading
> them back, writing 0's and 1', reading them back.  Writing with
> ">" which I think waits for completion.  In any case, that's not my
> problem.  The problem is that if I read the data back off the floppy
> then the OS reads from a buffer, not from the floppy.  At least that's
> how I understood it to work (and think I remeber observing) on Linux
> where I wrote the first version of the script.  More below.

Are you saying you do something like this?:

  cat > /dev/rfd0

If yes, then indeed, when the command is done, the stuff is written.

">" is a bad idea with raw devices though, because they will insist on
being read/written in block-sized pieces.  Stdio doesn't always do this
but things like tar and dd will - or can be persuaded to.

Quote:

>> When I need to "verify" a removable medium like a floppy or a tape,
>> I usually just dd it from the raw device into /dev/null.

> I think that only detects errors in the floppy formatting.  I'm

Yes, in a way.  I've always found that that is the source of problems
with removable media though.  I trust the OS to write what I tell
it to.  I boldy assume that if (1) the write succeeded and (2)
something can be read back that this implies what I wrote can be
read.

Quote:> letting the "fdformat" command (with verification) handle that part.
> I don't know if that even touches the data bytes.  I'd be nice to
> know what it does.

It formats and then reads to be sure that the tracks actually work.
For bulk diskette handling, your best bet is to format without verify,
then write, then verify what you've written.  The extra verification
after formatting is mostly wasted since, on average, the media is okay
and you're going to go and verify it afterwards anyway.

Quote:

>> Reads to the raw device (/dev/rfd0) ALWAYS translate into physical
>> reads.  There is no buffering.

> Now THAT's interesting.  Sounds like the buffers don't exist and so
> don't need to be dirtied on FreeBSD.  Guess I should try some
> experiments and try to verify that for my own satisfaction.  I must
> admit to not experimenting with my FreeBSD version.

Not just FreeBSD; all Unixen do this.  I think it is a Posix spec.
I said reads, but the same goes for writes too.

Quote:> Thanks much.

Pro noblem,

============================================================

Ottawa, ON             FreeBSD: Where you want to go. Today.

On Wed, 25 Jul 2001 20:09:56 GMT

GB> ">" is a bad idea with raw devices though, because they will insist on
GB> being read/written in block-sized pieces.  Stdio doesn't always do this
GB> but things like tar and dd will - or can be persuaded to.

        There is no block/character device distinction in FreeBSD so this no
longer applies. All devices are character devices.

--
    Directable Mirrors - A Better Way To Focus The Sun

                        http://www.best.com/~sohara

This is not a block/character issue.  Watch:

dd: /dev/rfd0: Invalid argument

1+0 records in
1+0 records out
512 bytes transferred in 1.350958 secs (379 bytes/sec)

If bs=511 it fails, but if bs=512 it works.  Multiples of 512
are required for this device.

============================================================

Ottawa, ON             FreeBSD: Where you want to go. Today.

On Tue, 31 Jul 2001 22:58:52 GMT

GB> >     There is no block/character device distinction in FreeBSD so this no
GB> > longer applies. All devices are character devices.
GB> >
GB>
GB> This is not a block/character issue.  Watch:
<snip example>

        So I see, my main point was that /dev/rfd0 and /dev/fd0 are the
*same* (9,0), I had thought (without testing) that this would imply that
blocking is irrelevant, actually it seems that it is inescapable.

--
    Directable Mirrors - A Better Way To Focus The Sun

                        http://www.best.com/~sohara