Re: philosophy of mounting things in unices

From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 01/07/05 

Date: Fri, 7 Jan 2005 21:35:46 +0100

Rod Smith <rodsmith@nessus.rodsbooks.com> wrote:
> In article <crknk8$43s$1@nntp.itservices.ubc.ca>,
> unruh@string.physics.ubc.ca (Bill Unruh) writes:
> >
> >>>The need to explicitly unmount floppies has to do with the fact that
> >>>Linux buffers floppy accesses, just like Linux (and Windows) buffers hard
> >>>disk accesses. For instance, if you mount a floppy and then copy some
> >>>files to it, the floppy drive might not spring to life immediately;
> >
> > Is it not possible to mount it in such a way that all writes are done
> > immediately and not buffered?
>
> The "sync" option (as in "mount -o sync /dev/fd0 /mnt/floppy") should do
> at least some of this; it causes the system to write data to floppy as
> soon as possible rather than buffer it. I'm not sure how far it goes,
> though; I can't guarantee that this will actually ensure that a floppy

You are correct. It's a FS-only option and doesn't affect either the
kernel or the underlying block driver.

The only way of accessing a block device without buffering is to do
direct i/o to it (open with O_DIRECT) or bind it to a raw character
device and do the i/o to the character device. Character devices
are not buffered.

But you can't mount a FS on a character device, and both raw and direct
i/o must be aligned at page (block?) boundaries both at the target (the
device) and the source (a mamory buffer) end, and I don't know of any
file systems or generic applications that do that.

That said, I did write over new year a serial-to-block device driver
that supports arbitrary (unaligned) access.

   ftp://oboe.it.uc3m.es/pub/Programs/bs-1.0.tgz

but it's still a serial device - it works by sending a block at a time
to the bound blck device and jolly well waiting until it's notified of
completion before proceding.

You could change the floppy block driver itself to act like that -
jolly well take only one request at a time and block everything until
its treated - but it wouldn't stop the kernel buffering at higher
levels, both in the VMS and in the FS buffers/caches.

So it looks like that's a loser. One's always going to end up with
buffering in the kernel.

The only hope would be to rewrite the higher layers - block i/o and fs
support - all the way through to support unbuffered modes, and uh, I'm
not going to do that.

> will be in a consistent state once the activity light goes out. The mount
> man page also says that it doesn't work with all filesystems, but it

It may work with vfat. It doesn't work with ext2 - to illustrate try
writing with two processes streaming at once to the end of the same file.
Now, if the fs is sync, then one process should run, stop, then the
other should run and stop. But that's not what happens under ext2 -
instead one process will run to the file, nice and sync, while the
other proces will simultaneously run to memory, filling up buffers,
which after the first process has finished then get flushed to the
file.

Maybe one could make the processes sync more by getting each to read
then write in turn - I seem to recall that posix allows weird ordering
behaviours if you do consecutive i/o of one kind only.

> doesn't give specifics, except to say that the option does work with
> ext2fs and ext3fs.

It does something, but that something is not always what it should be
or what you might expect it to be.

> In any event, I wouldn't recommend using this option
> and then ejecting floppies without first unmounting them. Linux just
> wasn't designed to be used in that way, and even aside from the floppy
> consistency issue, you might end up confusing Linux -- making it think
> something's mounted when it's not, thus causing problems when you try to
> access another floppy, for instance.

Fair enough!

> Another option might be to use the mtools package. This set of programs
> lets you copy files to and from FAT floppies, create directories, etc.,

Well, this works in sync mode because presumably it takes care to run
"fsync" after ever write of a single block, or any write at all. Yes -
support at the application level for sync will work, and does.

> without mounting the floppies. It uses DOS-style commands with "m"
> prepended (as in mdir, mcopy, etc.), and it's pretty convenient for quick

Peter

Relevant Pages

  • Re: count2.asm
    ... > I/O - this is useful when dealing with very large files. ... > control of how the buffering is done, ... > avoids wasting filesystem cache. ... Data from disk goes right to the memory ...
    (alt.lang.asm)
  • Re: How to speed up creation of an ASCII-file?
    ... How can I put some pepper in the creation of these ASCII-files? ... Many Fortran ... other than stdout may be changed to full buffering by the keyword -assume ... I have also seem systems that were supposedly fast I/O systems ...
    (comp.lang.fortran)
  • Re: z/OS 1.9 Features summary
    ... I beg to differ right back, the default buffering is 2, according to the ... IBM Manuals. ... efficient way to do I/O. ...
    (bit.listserv.ibm-main)
  • Re: open vs. fopen
    ... Keith Thompson wrote: ... Presumably there can be some buffering in the lower-level ... and terminal i/o is usually line-buffered. ... to most operating systems). ...
    (comp.lang.c)
  • Re: xlib vertical sync callback
    ... sync with xlib. ... isn't double buffering some way of doing what he wants? ... Standard Xlib doesn't ever explicitly mention ...
    (comp.windows.x)