Write protected floppies should be mounted read-only
Backup backup backup.
Words to live by. Nobody every regretted making a backup. In preparation for my talk,
I formated, labeled, and newfs’d a floppy and copied the
StarOffice talk to it. I also flicked over the write-protect tab for a bit of added
protection.
To test the floppy, I did this on another box:
# mount /dev/fd0 /mnt
# cp /mnt/oclug-sdd.tgz /home/dan/talks/
# umount /mnt
# umount: unmount of /mnt failed: Input/output error
Hmmmm, we tried many things. umount -f /mnt didn’t help. After
talking to some folks in the know, we figured it out. We found this in
/var/log/messages:
Jan 2 19:28:26 xeon /kernel: fd0c: hard error writing fsbn 16 of 16-18 (ST0 40<abnrml> ST1 2<write_protect> ST2 0 cyl 0 hd 0 sec 17)
Jan 2 19:28:26 xeon /kernel: fd0c: hard error writing fsbn 56 of 56-63 (ST0 40<abnrml> ST1 2<write_protect> ST2 0 cyl 1 hd 1 sec 3)
Jan 2 19:28:26 xeon /kernel: fd0c: hard error writing fsbn 240 (ST0 40<abnrml> ST1 2<write_protect> ST2 0 cyl 6 hd 1 sec 7)
That indicates the system was trying to write to the floppy and was failing because the floppy was
write-protected. Ummm, but why was it trying to write? I hadn’t written anything. I only copied
something off the disk. What’s going on?
Access time
If a file is accessed, the access time on the file is updated. That’s what was being updated.
That’s why the system was trying to write to the floppy. Access time is useful if you are trying
to find out how “used” a file is. If it’s not been access in a while, why keep it around?
Consider this example:
$ touch test
$ ls -l test
-rw-r--r-- 1 dan dan 0 Jan 2 19:07 test
$ ls -lTu test
-rw-r--r-- 1 dan dan 0 Jan 2 19:07:10 2002 test
$ more test
$ ls -lTu test
-rw-r--r-- 1 dan dan 0 Jan 2 19:07:25 2002 test
$ ls -lT test
-rw-r--r-- 1 dan dan 0 Jan 2 19:07:10 2002 test
First I create a file, test. Then I view the details of the file. Then I view
the time full details (T) and the access time instead of the modification time
(u). Then I access the file using more and check the times
again. You’ll see how they change.
Work around
I was able to unmount the floppy by doing this:
- take out the floppy
- adjust the write-protect tab
- insert the floppy
umount /mnt
The right thing
The right thing to do is to mount the floppy read-only:
mount -r /dev/fd0 /mnt
Then I went back and tried again. No problems. The unmount worked fine.
I talked to some FreeBSD developers about this problem. They helped me to find out
the cause of the problem and come to the work around. Then they started talked about rewriting
the fd driver to take notice of the write-protect tab…. That’s an
interesting example of how things change. A problem comes up. Someone decides to solve it.
FreeBSD continues to grow.
Wouldn’t it be enough in this case just to mount the disk noatime? Floppy drives are so slow to begin with that I personally wouldn’t want to have access times recorded even if the disk was writeable.
Now there’s an option I didn’t know which existed. Good point.
Yes, you could mount it noatime. But that almost amounts to the same thing as readonly.
AFAIK, moves are under way in the fd driver to notice that a write-protected floppy has been inserted, and to automagically mount it read-only.
Why are we using floppies? Cost per kilobyte would suggest CD has replaced the floppy. I am sad to see it go, as it was nice to dump data and run but CDs w/ burncd being free and fast, go for that.
Servent of "I AM" wrote:
>
> Why are we using floppies?
Because they are small, cheap, and reliable.
> Cost per kilobyte would
> suggest CD has replaced the floppy. I am sad to see it go,
> as it was nice to dump data and run but CDs w/ burncd being
> free and fast, go for that.
A CD was not a option.
I take your point. But reliable is a relative term. We rely on boot floppies when we install. That’s sufficient reliabilty for the situation. And for what I needed to do in these circumstances.
since when is a floppy reliable?
Why use flopiies? We use write-protected floppies to keep our AIDE database on critical machines. If we get rooted, the bad-guy can’t change the AIDE db unless he is physically present to slide the write-protect tab on the floppy. An alarm gets set off if either AIDE finds an error or if AIDE is not run at least once an hour
Which also means that anytime I make a change on one of these machines, I have to remember to umount the diskette, slide the tab, remount it rw, remake the AIDE db, unmount, reslide, remount ro. In any round of security patches I generally set off at least one alarm inadvertantly.
What I heard! Try to work with write-protected floppy now don’t cause system panic? I woldn’t check, thank you…Many times before my box panics when I have fogrotten to check read-wtire curtain on floppy…I think fd0 driver MUST check read-write curtain before mounting and refuse to mount (or force to read-only), when curtain is open. For my pity, many developers hasn’t interest to correct this bug (O, very long-stading bug, since 2.2.5 🙂 ), said "Floppy is obsolete as media and non-interest". Probably, it is obsoleted. But device exist and supported. Why is it buggy?
That sounds similar to the <A HREF="/floppygpf.php">floppy cause gpf</A> issue I wrote about…
It’s long been known that removing a floppy and then unmounting it would cause the kernel to panic.
It’s also long been known that accessing a bad floppy disk will cause the kernel to panic.
rob
If you want help, please click on Forums, then Support.