[ENBD] Re: supermount works, but slightly off

[P.T. Breuer]

In article <20040513142449.GZ15281 at gentoo-npk.bmp.ub> you wrote:
> I have to ENBD (2.4.32pre) up and running on an LTSP system using KDE
> and supermount.  When a floppy is in the drive everything works
> beautifully, however, I wanted to see what would happen if I removed the
> supermounted floppy disk and then tried to access the mount.  The results
> of this test were a little unexpected.  I pulled the disk out while the

Well, not very unexpected - in the sense that yes, I don't know what
supermount does, so in my eyes it could do anything and I would not be
surprised!

I simply have no experience of it.  As far as I recall from other
peoples descriptions, supermount (1) probes the device continuously and
(2) provides a sort of "shadow cache" in the file system that maintains
the image of what used to be there when the drive goes away, and (3)
destroys the cached image when a new drive appears.  Feel free to
correct me.  I believe that (3) might include search and destroy
missions for mounted filesystems from the drive.

> file browser was still in the supermounted floppy directory - I then
> refreshed the directory listing, and to my surprise the floppy grinded
> for a second and then the file manager displayed the contents as if the
> floppy disk was still there!

Sounds like the cache. Isn't that what one expects? After all, surely
the supermount thing should be running on the client side if you expect
to get any sense out of it, not the server side?

> On the enbd-server side I can see all
> sorts of I/O errors, of course.

Why's that "of course"? What sort?

> At first I thought this was some sort of
> KDE thing, but the same thing happens in an ssh terminal using standard
> utils like 'ls', 'cp' and such.  Even stranger is the fact that I was
> actually able to create a new file on the now non-existent supermounted
> media and actually go so far as to edit and save it.

Sounds fair enough to me. Looks like the client doesn't know the remote
device is dead, which is consistent withe the server not knowing. The
enbd server only knows the device has gone if it can't open it. SO it 
sounds as though it can.

Shrug - devise some different test of when a device has gone and I'll
be happy to incorporate it.


> All the while the
> floppy drive grinds periodically as the ENBD and supermount try in vain
> to access the media that is no longer in the drive.  So, apparently the
> floppy's contents are being buffered and cached in memory and that cache

You've lost me. There is no "apparently" - this is precisely what
happens normally, for all devices. To convey information you'd have to
say WHERE this is happening and why it is not expected.

> is being displayed instead of the actual contents of the disk - which
> isn't even in the drive any longer.

Shrug. Floppy disk drives aren't sensitive to the presence or absence
of disks anyway.

> After a certain number of failures
> the results get more strange and the dir listing gets pruned, but

Well, sounds like the cached image is aging away.

> doesn't go away altogether, as if the cached contents of the disk get
> mangled.  Is this something in the way that supermount and enbd are
> interacting because when I use supermount on a locally mounted floppy
> and when the disk is ejected and you try to act on the supermount you,
> correctly, get a blank directory listing or an error.

I know nothing whatsoever about supermount. But enbd does not do any
interacting with it.

BTW I don't understand from the description WHERE supermount is
running. If it were the server side, you've lost me because enbd server
shoudl be the only accessor, and the floppy should not be mounted.

> This is a snip of an strace on the ls command on a locally supermounted
> floppy

What is a "locally supermounted floppy"?

> in which I've removed the disk from the drive.  I'm not a C
> programmer, but I can infer a few things.  getdents64() seems to return,
> correctly, that there are "0 entries" and sure enough `ls /mount/floppy`

Oh - looks like a mount.

> returns nothing:
> 
> > open("/mnt/floppy", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> > fstat64(3, {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0
> > fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
> > getdents64(3, /* 0 entries */, 1024)    = 0
> > close(3)                                = 0
> > exit_group(0)                           = ?

Well, that indicates that supermount is allowing opens of the device,
even though it's not there, and maybe explains why enbd cannot tell that
it is not there. Opens should fail.



> Now, here is the return of the same command when I have mounted the
> remote floppy (/dev/nda) on /mnt/floppy.

I don't understand quite what you mean. How does supermount fit in
here?

> Everythings looks pretty much
> the same except for it appears that two calls to getdents64() are made,
> the first returning "11 entries", the next returning "0 entries".  In
> this case, `ls /mnt/floppy` returns the 11 files that were on the
> removed floppy disk:

I'm afraid I don't understand the setup, so I can't understand anything
by the strace. This shows the same kind of thing as before. I'd need
some explanation of what the setup is serverside.


> > open("/mnt/floppy", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> > fstat64(3, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
> > fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
> > getdents64(3, /* 11 entries */, 4096)   = 328
> > getdents64(3, /* 0 entries */, 4096)    = 0
> > close(3)                                = 0
> 
> Does anyone have any insight into why this might be happening, or where

I'm afraid I can't figure out what your setup is.

> I can start looking to resolve this?

It looks perfectly figurable out. But first need some simple data on
what is where and how. To me it looks as though opens on the floppy
device /dev/fd0 succeed serverside, even when the floppy is removed.
What have you done to cause that?

Peter