Re: [OpenAFS] How to stop the access to an AFS volume ?
On Wednesday 27 October 2004 19:57, Jeffrey Hutzelman wrote: > On Wednesday, October 27, 2004 09:26:49 +0200 giovanni bracco > >> In my AFS cell many volumes have an anomalous Vol ID: it can be seen in >> the previous example: ID=2258391753 > > Ow. I didn't notice that until you pointed it out. > I'm not sure I want to know how you got such large volume ID's. > we haven't not understood that; it happened quite long ago, so it means we have a substantial numer of volumes with "anomalous" ID number. > > Now I would like to go back to a normal situation, so that I can use > > OpenAFS software on file server. > > To attain this I have to convert volumes with anomalous Vol ID into > > standard volumes and I have seen that I can do that by a vos dump and > > vos restore sequence. > > You can, but you should be aware that anytime a volume ID is needed for a > new volume and you didn't provide one (and there are cases where you > _cannot_ provide one, such as with the temporary ID's used during volume > moves), an ID is allocated by asking the vlserver for the "next available" > volume ID. This is managed using a counter kept in the VLDB, so if you > want to stop having huge volume ID's, you will need some way to reset the > counter. I do not believe there is currently any interface for this, which > means you'll need to either write some code, convince someone else to do > so, or manually modify the database (rather perilous). Yes, I have looked into that. I have seen that the relevant value is the value MaxVolumeId which can be retrieved giving on the dbserver the command: vldb_check -vheader /usr/afs/db/vldb.DB0 I have also understood that the exact meaning of MaxVolumeId is "the volume ID for the next volume to be created". I have also located the position in the vldb.DB0 file where the value MaxVolumeId is stored and I have prepared a script to change it by using xxd and sed utility programs. It works nicely. I have tried it on a test cell and I am confident to be able to apply it on our production cell. On the test cell have selected the machine which is the sync site and I have run on that a script which does the following: 1) stop the vlserver 2) apply the patch on vldb.DB0 3) restart the vlserver All that takes just a few seconds, so soon after the restart the same dbserver is again the sync site for vldb. At that point when a new volume is created it is created with the new "good" id and the value of MaxVolumeId is updated on all the other dbservers. I have also noticed, it may be obvious of course, that just changing the MaxVolumeId in the vldb.DB0 does not triggers the update on the other dbservers. The update happens only when a new volume is created. Of course I can also stop all the vlservers, patch all the vldb.DB0, and restart them but I don't think is really necessary. > > > I would like to be sure that any user is not able to make any > > modification to a selected volume while the vos dump and vos restore > > sequence is in progress and that is the reason to look for a "off-line" > > feature. > > Alas the vos offline command seems not to be what I was looking for. > > I do not envy you the problem you have on your hands. Changing volume ID's > is not going to be transparent no matter what you do -- clients cache > name-to-ID lookups, so once you "renumber" a volume any clients that care > will have to do an 'fs checkv' in order to notice the change -- and I'm not > positive even that will work (it should be easy to test). I will make tests on all that: thank you for pointing out that kind of problems. > > However, I do think you can get the effect you want, in one of at least > acouple of ways. They're both going to involve building some stuff of your > own... > > > (1) Build yourself a patched copy of vos in which 'vos dump' leaves the > volume offline after dumping it. This is a relatively simple change in > src/volser/vsprocs.c:UV_DumpVolume(). Just above the error_exit: label, > you want to insert a call to AFSVolSetFlags() to set the volume's flags so > it stays offline after the transaction. You can copy the relevant call > from UV_SetVolume(); you want the third parameter to be VTOutOfService. > > With this approach, the volume will go offline when you start the dump, and > will stay that way after the dump is complete. As with 'vos offline', the > state is temporary, so if the fileserver restarts the volume will go online > again. > > > (2) Build the vol-bless and vol-unbless utilities, which allow you to > manipulate the persistent "Blessed" bit on a volume. Unblessing a volume > will take it out of service indefinitely. You should still be able to dump > and restore the volume without problems. The state of the "blessed" bit is > recorded in the volume dump, so the newly-restored volume may have to be > manually blessed before it will be available. > > The downside here is that vol-bless/vol-unbless must be run on the > fileserver co
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Ian Delahorne <[EMAIL PROTECTED]> writes: > "Todd M. Lewis" <[EMAIL PROTECTED]> writes: > >> It's convenient not to type ".unc.edu" a couple hundred times a >> day. Whether it's worth it is an open question. (BTW, >> '/afs/isis.unc.edu' is also a mount point for volume 'root.cell'.) > > And I thought that was what the TAB key was for. requires stat'ing the directory which has always been a no-no in /afs... With dynroot it's a bit better, but it's still an issue if you're not using dynroot. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
"Todd M. Lewis" <[EMAIL PROTECTED]> writes: > It's convenient not to type ".unc.edu" a couple hundred times a > day. Whether it's worth it is an open question. (BTW, > '/afs/isis.unc.edu' is also a mount point for volume 'root.cell'.) And I thought that was what the TAB key was for. -- /Ian D [EMAIL PROTECTED] - www.assv.net ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel Panic with arla
On Wed, 27 Oct 2004, vinod kumar boppana wrote: i am using arla on tru64(alpha) machines. might be clever to ask the arla-drinkers list, then. ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] How to stop the access to an AFS volume ?
On Wednesday, October 27, 2004 09:26:49 +0200 giovanni bracco <[EMAIL PROTECTED]> wrote: vos offline During the offline period the volume is marked by "busy" status e.g.: [EMAIL PROTECTED] bologna]$ vos examine user.bracco_bol Volume 2258391753 is busy so I can NOT make any action on the volume: vos dump -server f50.bologna.enea.it -partition c -id user.bracco_bol -file /tmp/vol_user.bracco_bol Could not start transaction on the volume 2258391753 to be dumped VOLSER: volume is busy Error in vos dump command. VOLSER: volume is busy Yeah; that's going to happen. You will get the busy-volume volume behaviour during a dump even without vos offline, but from what you say below it sounds like you actually want the "old" volume to be permanently offline until you replace it with the new one. In my AFS cell many volumes have an anomalous Vol ID: it can be seen in the previous example: ID=2258391753 Ow. I didn't notice that until you pointed it out. I'm not sure I want to know how you got such large volume ID's. Now I would like to go back to a normal situation, so that I can use OpenAFS software on file server. To attain this I have to convert volumes with anomalous Vol ID into standard volumes and I have seen that I can do that by a vos dump and vos restore sequence. You can, but you should be aware that anytime a volume ID is needed for a new volume and you didn't provide one (and there are cases where you _cannot_ provide one, such as with the temporary ID's used during volume moves), an ID is allocated by asking the vlserver for the "next available" volume ID. This is managed using a counter kept in the VLDB, so if you want to stop having huge volume ID's, you will need some way to reset the counter. I do not believe there is currently any interface for this, which means you'll need to either write some code, convince someone else to do so, or manually modify the database (rather perilous). I would like to be sure that any user is not able to make any modification to a selected volume while the vos dump and vos restore sequence is in progress and that is the reason to look for a "off-line" feature. Alas the vos offline command seems not to be what I was looking for. I do not envy you the problem you have on your hands. Changing volume ID's is not going to be transparent no matter what you do -- clients cache name-to-ID lookups, so once you "renumber" a volume any clients that care will have to do an 'fs checkv' in order to notice the change -- and I'm not positive even that will work (it should be easy to test). However, I do think you can get the effect you want, in one of at least acouple of ways. They're both going to involve building some stuff of your own... (1) Build yourself a patched copy of vos in which 'vos dump' leaves the volume offline after dumping it. This is a relatively simple change in src/volser/vsprocs.c:UV_DumpVolume(). Just above the error_exit: label, you want to insert a call to AFSVolSetFlags() to set the volume's flags so it stays offline after the transaction. You can copy the relevant call from UV_SetVolume(); you want the third parameter to be VTOutOfService. With this approach, the volume will go offline when you start the dump, and will stay that way after the dump is complete. As with 'vos offline', the state is temporary, so if the fileserver restarts the volume will go online again. (2) Build the vol-bless and vol-unbless utilities, which allow you to manipulate the persistent "Blessed" bit on a volume. Unblessing a volume will take it out of service indefinitely. You should still be able to dump and restore the volume without problems. The state of the "blessed" bit is recorded in the volume dump, so the newly-restored volume may have to be manually blessed before it will be available. The downside here is that vol-bless/vol-unbless must be run on the fileserver containing the volume whose blessed bit you want to manipulate. Also, while these utilities are fairly simple, the code is somewhat old and may not build cleanly. If you want copies of these tools, let me know and I'll try to produce a version I can distribute (really, I should submit patches, but there are only so many hours in the day...). -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Derrick J Brashear <[EMAIL PROTECTED]> writes: > Which cell is /afs/cs? That's local policy. But that's fine. Real references should use the full path. The shorthand is for user convenience. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
>Something that has come up with respect to the use of dynamic roots is >that the dynamic roots support mountpoints but not symlinks. >Organizations which have symlinks in their root.afs find using dynamic >roots on laptops to be extremely difficult if not impossible. There is (at least on Unix systems) a "CellAlias" file for use with dynroot. We use that for a few local cells. --Ken ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
On Wed, 27 Oct 2004, Derek Atkins wrote: Jim Rees <[EMAIL PROTECTED]> writes: 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb Which cell is /afs/cs? ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
On Oct 27, 2004, at 5:34 AM, Todd M. Lewis wrote: Joshua Johnson wrote: > So, at the risk of starting something here, I am going to ask what other peoples experiences are with placing /usr/local in AFS and sharing among machines of same @sys type (much like the AdminGuide suggests). I think it depends on how much administrative control you expect to have over the machines in your local cell. When we first put our cell together, we had complete control and put /usr/local in AFS. (We made a complete mess of it, too, but it was totally our mess, so we could deal with it. That's another story though.) Eventually, however, other research groups and departments joined the cell and local admins had their own notion of what the "local" in /usr/local meant. At least one group already had a shared /usr/local that wasn't in AFS... That's really the age-old question of "what does the local in /usr/local mean?" The last two places that I have worked have decided that: - "/usr/local" means "local to the corner of the network we control". It points into a particular spot in our AFS cell isn't advertised to the other departments (and that we refuse to answer questions about if they find it). - Some people insist that it should be "local to the machine itself" ... for that we use "/local". Those utilities are installed on the machine itself, and are things that we feel should NEVER live in any kind of network location (kerberos and ssh being the big ones, but also things which are essential to the stand-alone operation of the system so that it doesn't hang or become useless if AFS goes down, or becomes unreachable, for those systems we feel need to stay up even when AFS is down). - For "local to the larger concept of our site" and "things we have to let sysadmins and maybe users in other departments look at", there's something that gets referenced as "/usr/athena" which is then a symlink out into AFS space. It's called that because we have been using athena, but in the future we could decide to call it "/usr/ucsc" or something. Putting the 1st and 3rd out in AFS has worked pretty well for us. What didn't work for us was having certain key utilities in AFS (before I got here, the "/local" thing didn't exist, yet we had machines leaving a lot of their main functionality out in AFS, which caused us no end of headaches -- not being able to access a machine to shut it down because its kerberos libraries are out in AFS , and there's some problem interfering with the network which keeps it from accessing its kerberos libraries, is just WRONG). ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Mount points is worse. At least with a symlink you can "pwd" and get a correct global name. But if you are going through a local mount point, that won't work. ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Derek Atkins wrote: Jim Rees <[EMAIL PROTECTED]> writes: 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb Is there a good reason why /afs/athena should be a symlink and not a second mount point? Something that has come up with respect to the use of dynamic roots is that the dynamic roots support mountpoints but not symlinks. Organizations which have symlinks in their root.afs find using dynamic roots on laptops to be extremely difficult if not impossible. Some organizations have done something similar to Doug except that instead of /usr/afsws -> /afs/anl.gov/@sys/usr/afsws being a symlink in the local file system they are creating afsws -> anl.gov/@sys/usr/afsws in the root.afs volume. Maybe the answer is to add symlink support to dynamic roots but I think we want to document that this kind of setup should be avoided. Or am I completely nuts? Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Jim Rees <[EMAIL PROTECTED]> writes: > 3. (Optional) Create a symbolic link to a shortened cell name, to reduce > the length of pathnames for users in the local cell. For example, in the > abc.com cell, /afs/abc is a link to /afs/abc.com. > > That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
> That really needs to be removed from the documentation. I don't agree at all. It's listed as optional and has been there for ages. It perhaps needs additional wording about the ramifications, but should not be deleted IMO. Not a single cell in our internal network will ever participate in the global AFS namespace. We've used that optional step as part of our cells for 12 years now. Global namespace as "one of the most important features of AFS" is incredibly subjective. ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
On Wed, 27 Oct 2004, Jim Rees wrote: > '/afs/isis' is a symbolic link, leading to a mount point for > volume 'root.cell'. > > So you broke one of the most important features of afs, the global name > space. Why? Huh? Transarc trainers specifically taught to do exactly this 15 years ago. The recommendation was there to still use the FQDN in all symlinks, scripts, etc. But it was recommended to have it for typing ease. Remember /afs/tr ? -Mitch ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Todd M. Lewis wrote: Jim Rees wrote: '/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'. So you broke one of the most important features of afs, the global name space. Why? 'Cause we're stupid? 'Cause I didn't want to make an already too long message even longer? 'Cause you followed the documentation? http://www.openafs.org/pages/doc/QuickStartUnix/auqbg002.htm#ToC_87 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. Steve - Stephen G. Roseman Lehigh University [EMAIL PROTECTED] ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Todd M. Lewis wrote: Joshua Johnson wrote: > So, at the risk of starting something here, I am going to ask what other peoples experiences are with placing /usr/local in AFS and sharing among machines of same @sys type (much like the AdminGuide suggests). Rather then /usr/local we have a /usr/afsws/local where /usr/afsws -> /afs/anl.gov/@sys/usr/afsws. We have a local volume for each arch. Users then just add /usr/afsws/local/bin in their path. We use depot to populate local volume with symlinks into AFS. This does require us to build the packages and to use --prefix and DESTDIR= to get all package references to point into AFS, but depot has made this quite easy. For security realted or packages including shared libs, we have these local on a machine. -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] How to stop the access to an AFS volume ?
On Wednesday 27 October 2004 15:12, you wrote: > giovanni bracco wrote: > > In my AFS cell many volumes have an anomalous Vol ID: it can be seen in > > the previous example: ID=2258391753 > > > > The Windows client uses "unsigned long" for all volume IDs. The Unix > client should probably switch to using "afs_uint32". > > Jeffrey Altman I have not looked in detail to AFS code but volumes with ID exceeding the signed integer capability have only partial functionality in AFS: for example if they are located in a file server with standard OpenAFS software (e.g. Linux) it is impossible to move them and also vos examine command does not work properly: #vos examine user.bracco_pro_00 Could not fetch the information about volume 2258391565 from the server : No such device Volume does not exist on server bracco.frascati.enea.it as indicated by the VLDB #vos move user.bracco_pro_00 bracco.frascati.enea.it a 43p.frascati.enea.it a Could not fetch the information about volume 2258391565 from the server : No such device vos:cannot access volume 2258391565 On the contrary volumes can be created and removed without problems, even with anomalous ID numbers, so probably the ID number has slightly different definition in different component of the package. GIovanni -- Giovanni Bracco ENEA INFO (Servizio Informatica e Reti) Via E. Fermi 45 I-00044 Frascati (Roma) Italy phone 00-39-06-9400-5597 FAX 00-39-06-9400-5735 E-mail [EMAIL PROTECTED] WWW http://fusfis.frascati.enea.it/~bracco ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Jim Rees wrote: '/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'. So you broke one of the most important features of afs, the global name space. Why? 'Cause we're stupid? 'Cause I didn't want to make an already too long message even longer? Actually, we thought it was convenient at first, and it's come back to bite us repeatedly. We try very hard to make all the references in packages spell the cell name out -- isis.unc.edu -- and I think we've got it that way almost everywhere. It's convenient not to type ".unc.edu" a couple hundred times a day. Whether it's worth it is an open question. (BTW, '/afs/isis.unc.edu' is also a mount point for volume 'root.cell'.) -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A man's home is his castle, in a manor of speaking. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
'/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'. So you broke one of the most important features of afs, the global name space. Why? ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] How to stop the access to an AFS volume ?
giovanni bracco wrote: In my AFS cell many volumes have an anomalous Vol ID: it can be seen in the previous example: ID=2258391753 The ID is very large and it is larger that the max value that can be managed by standard AFS code (signed integer). When the problem appeared in the past, Transarc provided us with a patched AFS version that is able to manage this kind of vol ID. Now I would like to go back to a normal situation, so that I can use OpenAFS software on file server. To attain this I have to convert volumes with anomalous Vol ID into standard volumes and I have seen that I can do that by a vos dump and vos restore sequence. I would like to be sure that any user is not able to make any modification to a selected volume while the vos dump and vos restore sequence is in progress and that is the reason to look for a "off-line" feature. Alas the vos offline command seems not to be what I was looking for. The Windows client uses "unsigned long" for all volume IDs. The Unix client should probably switch to using "afs_uint32". Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Pro's & Con's of /usr/local on AFS....
Joshua Johnson wrote: > So, at the risk of starting something here, I am going to ask what other peoples experiences are with placing /usr/local in AFS and sharing among machines of same @sys type (much like the AdminGuide suggests). I think it depends on how much administrative control you expect to have over the machines in your local cell. When we first put our cell together, we had complete control and put /usr/local in AFS. (We made a complete mess of it, too, but it was totally our mess, so we could deal with it. That's another story though.) Eventually, however, other research groups and departments joined the cell and local admins had their own notion of what the "local" in /usr/local meant. At least one group already had a shared /usr/local that wasn't in AFS... So we bit the bullet and converted everything to what in retrospect seems an obvious better alternative. /afs is a global name space, and as Jim Rees already pointed out, packages have to be tweaked to work well in almost any non-default tree. So we make our stuff self consistent in the /afs tree without trying to make it look like part of something more familiar. It's the only name space where we can be sure of not colliding with a "local" system or system administrator. Draw your own conclusions, your millage may vary, etc., but we're happy with what we've got now. I don't want to create too large of a thread so if this has been discussed, and there are pointers to studies/whitepapers/etc., please feel free to post/send links to me. I don't know of any, but it sounds like a good topic for a wiki page. Go for it. At the risk of bloating an already too long message, here's how we put packages together in our cell. Let's take the case of "ne" (yet another text editor that I happen to have contributed code to; std. self horn-blowing disclaimers here, see http://ne.dsi.unimi.it/ if you're that bored). In our cell, /afs/isis/pkg/ne/bin/ne is the path to the current default ne binary regardless of the architecture you happen to be on. '/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'. /afs/isis/pkg/ne is a symbolic link to /afs/isis/pkg/ne-136, 'cause 1.36 is the current version. There's also ne-119 and ne-133 in /afs/isis, so we're doing package versioning that way. Each of those is a mount point for the volumes pkg.ne-119, pkg.ne-133, and pkg.ne-136. The directory structure within, say ne-136 looks like this: lrwxr-xr-x bin -> .install/@sys/bin lrwxr-xr-x build -> .build/@sys drwxr-xr-x .build lrwxr-xr-x common -> .install/common lrwxr-xr-x dist -> .build/dist lrwxr-xr-x doc -> .install/common/doc lrwxr-xr-x etc -> .install/@sys/etc lrwxr-xr-x include -> .install/@sys/include drwxr-xr-x .info lrwxr-xr-x install -> .install/@sys drwxr-xr-x .install lrwxr-xr-x lib -> .install/@sys/lib lrwxr-xr-x libexec -> .install/@sys/libexec lrwxr-xr-x man -> .install/common/man lrwxr-xr-x sbin -> .install/@sys/sbin lrwxr-xr-x share -> .install/common/share lrwxr-xr-x src -> .build/src The extensive use of the @sys macro and symbolic links lets us keep architecture specific stuff separate, but use the same paths anyway. Note that '.build' is a mount point for volume 'pkg.nE-136', which is not replicated since it only contains what we need to build the package and isn't used otherwise. Volume pkg.ne-136 is replicated. Of course, this is way to complicated to do by hand; we've got a script that sets this structure up and handles the tricky parts. (It's at /afs/isis.unc.edu/pkg/admin/bin/pkg if you want it, but be warned it taylored for our cell.) We've currently got about 314 packages built this way, most of which have more that one version online. It's a pain to manage (and not my pain btw; somebody else in our group handles most of it), but per package deployment effort on individual machines is zero most of the time. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A hangover is the wrath of grapes. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Kernel Panic with arla
hai all, please help me . i am using arla on tru64(alpha) machines. the problem is : the machines on which a job is running(with the user home partition on afs) is getting rebooted around 04:20:00 (every day early morning) with the following messages in the logs. vmunix : trap: invalid memory ifetch access from kernel mode faulting virtual address : 0x pc of faulting instruction: 0x ra contents at the time of fault : 0xfc301578 sp contents at the time of fault : 0xfe04a0fd7790 panic : kernel memory fault. This is happening only if jobs are running on the machines at that time(04:20:00). please help me..
Re: [OpenAFS] How to stop the access to an AFS volume ?
On Tuesday 26 October 2004 17:42, Jeffrey Hutzelman wrote: > On Tuesday, October 26, 2004 10:13:42 -0400 Derrick J Brashear > > <[EMAIL PROTECTED]> wrote: > > On Tue, 26 Oct 2004, giovanni bracco wrote: > >> Is there a way to prevent users to access a selected AFS volume for some > >> time without affecting the access to the other volumes on the same or on > >> other file servers & partitions? > >> > >> I would like also to be able to stop any current activity on the volume > >> content. > >> > >> In our AFS cell I have observed that there is a small numer of Volumes > >> that appear as "Off-line" from vos examine or vos listvol command. > >> Typically these "Off-line" volume have another version which is marked > >> "On-line" on a different server/partition. > >> I have the impression that the only way to set a volume "off-line" is > >> from command vos restore -offline, is that true? > >> So off-line ha probably nothing to do with what I am looking for. > > > > You can use the hidden vos offline command. > > You can, but be aware that this status is represented as state in the > running fileserver, and will be lost if the fileserver restarts. > Thank you for the suggestion, I have tried the vos offline command: vos offline During the offline period the volume is marked by "busy" status e.g.: [EMAIL PROTECTED] bologna]$ vos examine user.bracco_bol Volume 2258391753 is busy so I can NOT make any action on the volume: vos dump -server f50.bologna.enea.it -partition c -id user.bracco_bol -file /tmp/vol_user.bracco_bol Could not start transaction on the volume 2258391753 to be dumped VOLSER: volume is busy Error in vos dump command. VOLSER: volume is busy --- It may be is better if I explain the reason for which I would like to put "off-line" a volume: In my AFS cell many volumes have an anomalous Vol ID: it can be seen in the previous example: ID=2258391753 The ID is very large and it is larger that the max value that can be managed by standard AFS code (signed integer). When the problem appeared in the past, Transarc provided us with a patched AFS version that is able to manage this kind of vol ID. Now I would like to go back to a normal situation, so that I can use OpenAFS software on file server. To attain this I have to convert volumes with anomalous Vol ID into standard volumes and I have seen that I can do that by a vos dump and vos restore sequence. I would like to be sure that any user is not able to make any modification to a selected volume while the vos dump and vos restore sequence is in progress and that is the reason to look for a "off-line" feature. Alas the vos offline command seems not to be what I was looking for. Any other suggestions? GIovanni -- Giovanni Bracco ENEA INFO (Servizio Informatica e Reti) Via E. Fermi 45 I-00044 Frascati (Roma) Italy phone 00-39-06-9400-5597 FAX 00-39-06-9400-5735 E-mail [EMAIL PROTECTED] WWW http://fusfis.frascati.enea.it/~bracco ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] How to stop the access to an AFS volume ?
Derrick J Brashear wrote: On Tue, 26 Oct 2004, giovanni bracco wrote: Is there a way to prevent users to access a selected AFS volume for some time without affecting the access to the other volumes on the same or on other file servers & partitions? You can use the hidden vos offline command. Note that this (together with Bob's suggestion to rename the volume) will be reflected to the application. What I sometimes miss: a 'vos vbusy' command, making clients receive VBUSY and causing them to retry after a few seconds. Could be useful on fileservers hammered for a single volume causing them to run into hundreds of calls waiting for a thread. Or if you quickly need to power-cycle a RAID controller with only a few volumes on it. We run with a mod to the fileserver that supports '-busyat 0' which gets started in cases disks/controllers need a short maintenance. That way applications hang for a while but at least don't fail. Still, the double stop/restart required for this is messy and the granularity too coarse. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rainer Toebbickehttp://cern.ch/rtb -or-[EMAIL PROTECTED] European Laboratory for Particle Physics(CERN) - Geneva, Switzerland Phone: +41 22 767 8985 Fax: +41 22 767 7155 ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
