On Sat, 24 Jun 2000, Khimenko Victor wrote:
> In <20000623232902.B30832@pcep-jamie.cern.ch> Jamie Lokier (lk@tantalophile.demon.co.uk) wrote:
> > Tigran Aivazian wrote:
> >> Then you come up with an idea of implementing a special
> >> filesystem 'nullfs' where you shift the open file to, instead of closing
> >> it. Any subsequent io on this fd gives EIO.
>
> > Nice, because you still have the path from the dentry. So you might be
> > able to forcibly unmount a filesystem (e.g. on a broken network file
> > server) moving everything to nullfs. And then you might be able to
> > mount a different fs in its place and use the paths from the dentries to
> > convert the nullfs references back into real file references.
>
> ... on backup server ? Yeah, it can be usefull. In this case all operations
> should return NOT IO error but "try again" (I'm not sure how applications
> will react - perhaps better way is to freeze application and notify some
> daemon).
ah.... now I understand what Jamie was talking about - it is extremely
interesting but it is probably order(s) of magnitude more complex to
implement than plain forced umount.
But I am still interested to think about it (in the background).
And yes, it is much safer to freeze the applications (inside whatever
this_fs-related system calls they were in) than to rely on them handling
EAGAIN literally.
Regards,
Tigran.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:04 EST