hurf@theory.tn.cornell.edu (Hurf Sheldon) (05/01/91)
We have 3 20gb HP servers which has added 192 partitions
to what I thought was an aready complex file system. Before
I try to reinvent the wheel what is out there for dealing
with these things and/or what have/would you do?
Using them as a glorified tape drive seems a waste.
The problems so far are:
What is on which disc when.
Who can mount the things - ( I tried a suid script to let users
mount them - it doesn't work and
I have no desire to make /etc/mount
suid)
What to do when the system crashes? Some of the disks have to
be mounted rw to be useful but at 20+mins a pop to fsck
the buggers, even 5 sides mounted rw is a pain.
Thanks,
hurf
--
Hurf Sheldon Network: hurf@theory.tn.cornell.edu
Program of Computer Graphics Phone: 607 255 6713
580 Eng. Theory Center, Cornell University, Ithaca, N.Y. 14853 brucet@hpfcdc.HP.COM (Bruce Thompson (greeley temp)) (05/04/91)
>We have 3 20gb HP servers which has added 192 partitions >to what I thought was an aready complex file system. Before >I try to reinvent the wheel what is out there for dealing >with these things and/or what have/would you do? >Using them as a glorified tape drive seems a waste. Agreed! >The problems so far are: >What is on which disc when. >Who can mount the things - ( I tried a suid script to let users mount them - it doesn't work and I have no desire to make /etc/mount suid) >What to do when the system crashes? Some of the disks have to >be mounted rw to be useful but at 20+mins a pop to fsck >the buggers, even 5 sides mounted rw is a pain. This will change in 8.0. All the cartridges can be mounted rw. If power is lost or the system crashes, only those cartridges that were in the drives at the time need to fscked. Cartridges that were in the slots (i.e. not in drives) have their file systems marked clean. Note this does not mean that cartridges in slots can not be accessed. All file systems that have been "mounted" via mount(1m) still appear available to users. What this means to you is that all the cartridges can be mounted rw at boot time at the desired mount points. Users do not have to mount a cartridge, access it, then unmount it. You do not have to make /etc/mount suid! There are two exceptions to marking a mounted cartridge clean when it is removed from a drive. This first is if a named pipe is created on the surface. I guess you COULD put a named pipe on a surface but it wouldn't seem too optimum. :-) The second exception is when an unlinked-open file exists on the file system. This can cause file system blocks to be allocated but not associated with a file if the system crashes. The June 1990 USENIX conference proceedings has a paper discussing the design of the autochanger driver and its associated challenges like fsck. If you want I have an electronic copy (troff format) I could send you (or anyone else interested). It's a little too big to post. The title is "A Transparent Integration Approach for Rewritable Optical Autochangers", page 119. Bruce Thompson Hewlett Packard Greeley Storage Division brucet@hpgrlf "Assume standard disclaimer here"
curt@OCE.ORST.EDU (Curt Vandetta) (05/09/91)
In article <5570622@hpfcdc.HP.COM> you write: >What this means to you is that all the cartridges can be mounted rw >at boot time at the desired mount points. Users do not have to >mount a cartridge, access it, then unmount it. You do not have >to make /etc/mount suid! Does this mean that when a user types bdf the autochanger makes a lot of noise and returns in about a minute? What happens when I try and "sync" the machine before I shut it down? It seems that the mechanical delays in the autochanger would negate sync's efficiency. >Bruce Thompson >Hewlett Packard >Greeley Storage Division >brucet@hpgrlf Thanks, Curt
brucet@hpfcdc.HP.COM (Bruce Thompson (greeley temp)) (05/14/91)
>>What this means to you is that all the cartridges can be mounted rw >>at boot time at the desired mount points. Users do not have to >>mount a cartridge, access it, then unmount it. You do not have >>to make /etc/mount suid! >Does this mean that when a user types bdf the autochanger makes >a lot of noise and returns in about a minute? What happens when >I try and "sync" the machine before I shut it down? It seems that >the mechanical delays in the autochanger would negate sync's >efficiency. The bdf (and df) command has been modified in 8.0 to not cause all mounted file systems in the autochanger to be inserted into a drive. It grabs all the information it needs from kernel memory, therefore no cartridge swaps are performed. The function of "sync" is to schedule up dirty buffers to be written out to the disk. What happens with the autochanger is that before a cartridge is removed from the drive, all the dirty buffers are flushed out. Thus when "sync" runs , it won't find any of those old dirty buffers so no extra cartridge swaps will be performed. Any new dirty buffers created since the last time the cartridge was inserted will be written out the next time the cartridge is inserted. As for shutting down the system, when "umount -a" runs it will unmount all mounted file systems. Since cartridges which are "mounted" but stored in slots have all the system buffers flushed and the superblock marked clean, only the kernel data structures are cleared. Cartridges currently in drives will be ejected an returned to their slots. Thus the time to shutdown a system with an entire autochanger filled with cartridges mounted read-write is only increased by a few seconds. Bruce Thompson