[DaveM: it's not clear to me if the linux-fsdevel list is for VFS
dicussions or for *all* FS development discussions]
Michael Wilhelm writes:
> I am looking for a tapefs or some type of program that may make a
> nfs server using the tapedrive as a disk drive or a ftp server that
> uses the tape drive as a disk drive... I have seen
> unitree(www.unitree.com) but its not for linux.. any suggestions?
I'm not entirely sure what you mean by "tapefs". I looked at the
Unitree WWW pages and it appears the only product they offer is a
heirarchical file storage system. This is a system which will backup
unused files to long-term storage media (i.e. tapes). The file entry
still appears in the filesystem (as would the inode permissions and
such), it's just that the data blocks are marked as not available.
When a process tries to access the data blocks in such a file, the
data is migrated back to disc (obviously this can be a slow
operation:-). These systems have a robot tape-loading machine
associated with them and a roomful of tapes.
However, this is not what I'd call a tapefs. I'd call it
a heirfs or something.
Our director here has pushed for this kind of system for around 10
years now :-) Unfortunately, they are quite expensive. Having such a
system (the heirfs software and an API to drive robots) for Linux
would certainly make it attractive to "big iron" users. I believe
there are some commodity tape robots which are affordable. A
commercial heirfs solution is likely to charge an awful lot just for
the software. A free Linux heirfs would get around that.
To me, a tapefs is a FS that allows me to mount a tape and gives the
appearance of a (cough) slow filesystem. This is something I've had
users (colleagues with large scientific datasets) ask me about, and is
something that would be quite handy.
Both these filesystems *could* be done in userspace, either by hacking
libc to wrap all the FS calls, or by creating a pseudo-NFS server
which "exports" it's FS which is locally mounted.
The libc hacking solution has the disadvantage of not working for
older applications using older C libraries or statically linked. It
also has the disadvantage of adding a layer and hence performance
overhead for *all* file accesses.
The pseudo-NFS server solution has the disadvantage of requiring all
file I/O for the FS to go through the NFS layers, which would
drastically reduce performance. For a heirfs, this is bad, since it
would be used for massive datasets, so the performance loss would
really hurt. For a tapefs, the loss might not be as great, since some
tapes (exebyte) tend not to be so fast anyway. A DLT, on the other
hand, is pretty fast, so once again going through NFS layers will
cause a noticable degradation.
So, implementing a real FS module for each of these systems would
probably be the right way to go. What we need is someone with the time
and energy to go forth and write code. Any takers?
Regards,
Richard....
-
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/