Re: [OpenAFS] Kernel module on sparc64
On Wednesday 06 December 2006 23:49, Jeffrey Hutzelman wrote: On Wednesday, November 15, 2006 09:44:56 AM +0100 Gunnar Krull [EMAIL PROTECTED] wrote: # modprobe libafs Found system call table at 0x4164b8 (exported) Found 32-bit system call table at 0x416000 (exported) (Shouldn't it be a 64-bit system call table ?) There are two tables - one for native programs, and one for 32-bit programs. We found both. * With OpenAFS 1.5.10 and 1.5.11 # modprobe libafs Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr=authtab That's normal; unless you patch your kernel to export this symbol or provide its address on the command line, the NFS translator will not be supported. Unlike the system call table, this is not something we can scan for. # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 That's the whole trace? That's pretty useless. But no, this is not the cause of your problem. Yes, that's the whole trace. Nothing more the kernel want's to say. The same result now with version 1.5.12. I think that's the reason why my token gets discarded when trying to access a protected folder of our afs filespace: afs: Tokens for user of AFS id 1032 for cell ** are discarded (rxkad error=19270410) 19270410 is RXKADSEALEDINCON, which effectively means that either you or the fileserver is not encrypting data correctly. Usually it means that one of you is using the wrong key, but in this case, there is a known problem on some 64-bit platforms, which should be fixed in the next release. The encryption and keys on the server side are correct. I've checked this to be sure that the problem is the client. Sparc64 in combination with Linux/Debian is the only effected architecture here. So, I'm waiting impatiently for the fixed release ... The 1.5.11 version improves the amd64 system call table range checking. Is this also the case for sparc64 systems? IIRC, the issue in question only affected amd64 systems. -- Jeff Thanks a lot for your answers! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
Gunnar Krull [EMAIL PROTECTED] and others wrote: ... I think that's the reason why my token gets discarded when trying to access a protected folder of our afs filespace: afs: Tokens for user of AFS id 1032 for cell ** are discarded (rxkad error=19270410) 19270410 is RXKADSEALEDINCON, which effectively means that either you or the fileserver is not encrypting data correctly. Usually it means that one of you is using the wrong key, but in this case, there is a known problem on some 64-bit platforms, which should be fixed in the next release. The encryption and keys on the server side are correct. I've checked this to be sure that the problem is the client. Sparc64 in combination with Linux/Debian is the only effected architecture here. So, I'm waiting impatiently for the fixed release ... This sounds like it might be the same problem that Steve Roseman [EMAIL PROTECTED] ran into on powerpc. In his case, his cache manager was using wrong-endian encryption right at the point of setting up an encrypted rx connection with a fileserver, so wasn't in fact capable of doing authenticated file access. The definitive proof would be to use tcpdump knowledge of the keys used to prove this is what happening, but you probably won't need to do that. I would be *very* interested in knowing two things: /1/ do pts and other userland commands work while using authenticated access with a token immediately before you access afs filespace and lose that token? ( since your error report contains your vice id, this seems likely to be true. ) /2/ does this build fix produces a working cache manager for you? The simple kludge is to just append the line #define WORDS_BIGENDIAN 1 at the end of src/config/afsconfig.h after configuring afs, then at the top do ( cd src/libafs; make clean ) -- if you have old kernel objects in your build tree make only_libafs -- build just the cache manager You can then copy the cache manager pieces to your already existing system. Of course you can also build the whole thing. Just remember that if you type configure or config.status you'll have to patch afsconfig.h again. If these are both true, then that's good, that means I may actually have an interesting patch that will help you as well as others shortly. Also, you'll have a working cache manager, and won't need to be quite so impatient. :-) -Marcus Watts ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Thursday 07 December 2006 10:03, Marcus Watts wrote: Gunnar Krull [EMAIL PROTECTED] and others wrote: ... I think that's the reason why my token gets discarded when trying to access a protected folder of our afs filespace: afs: Tokens for user of AFS id 1032 for cell ** are discarded (rxkad error=19270410) 19270410 is RXKADSEALEDINCON, which effectively means that either you or the fileserver is not encrypting data correctly. Usually it means that one of you is using the wrong key, but in this case, there is a known problem on some 64-bit platforms, which should be fixed in the next release. The encryption and keys on the server side are correct. I've checked this to be sure that the problem is the client. Sparc64 in combination with Linux/Debian is the only effected architecture here. So, I'm waiting impatiently for the fixed release ... This sounds like it might be the same problem that Steve Roseman [EMAIL PROTECTED] ran into on powerpc. In his case, his cache manager was using wrong-endian encryption right at the point of setting up an encrypted rx connection with a fileserver, so wasn't in fact capable of doing authenticated file access. The definitive proof would be to use tcpdump knowledge of the keys used to prove this is what happening, but you probably won't need to do that. I would be *very* interested in knowing two things: /1/ do pts and other userland commands work while using authenticated access with a token immediately before you access afs filespace and lose that token? ( since your error report contains your vice id, this seems likely to be true. ) Yes, that works. I can e.g. create and remove user groups with pts. Creating/removing volumes per vos command also works. Interestingly: after my token got discarded I can still execute commands that need authentication (pts, vos, ...) !? /2/ does this build fix produces a working cache manager for you? The simple kludge is to just append the line #define WORDS_BIGENDIAN 1 at the end of src/config/afsconfig.h after configuring afs, then at the top do ( cd src/libafs; make clean ) -- if you have old kernel objects in your build tree make only_libafs -- build just the cache manager You can then copy the cache manager pieces to your already existing system. Of course you can also build the whole thing. Just remember that if you type configure or config.status you'll have to patch afsconfig.h again. If these are both true, then that's good, that means I may actually have an interesting patch that will help you as well as others shortly. Also, you'll have a working cache manager, and won't need to be quite so impatient. :-) Yes, that's it! Now I can open files and directories in authentication only area of our afs filespace and the token resides in my system. I will test it more in the next days but it should be ok now. Thanks for the hint! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Thu, 7 Dec 2006, Gunnar Krull wrote: # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 I'd guess we try unmapping a proc entry we didn't install, but, not your problem. 19270410 is RXKADSEALEDINCON, which effectively means that either you or the fileserver is not encrypting data correctly. Usually it means that one of you is using the wrong key, but in this case, there is a known problem on some 64-bit platforms, which should be fixed in the next release. The encryption and keys on the server side are correct. I've checked this to be sure that the problem is the client. Sparc64 in combination with Linux/Debian is the only effected architecture here. So, I'm waiting impatiently for the fixed release ... That's good, but, until we know about it, we're not going to fix it, so you can hope that every one is it, and it won't be. Between the fix Marcus found for AIX, and the one I found for s390x Linux, I bet one is related. I will look in an hour or so. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
Jeffrey Hutzelman [EMAIL PROTECTED] writes: On Tuesday, November 21, 2006 04:16:51 PM +0100 Stephan Wiesand [EMAIL PROTECTED] wrote: But isn't loading such a module supposed to fail? Is it only in this special case that it doesn't, because of the weak definition of tasklist_lock in the AFS module and/or because of the fallback to rcu_read_lock? It is, except that our reference is weak, so we can detect at runtime whether the symbol is available to us. The kernel handles this case correctly; if a non-GPL module has a weak reference to a GPL-only symbol, the reference will be left unresolved, just as if the symbol were not present at all. One way to solve this is to make a compile-time check for the symbol and if it fails there then we don't run the runtime check, we ifdef it out. That way the build wont fail in modpost. -- Jeff -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 OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Undelete support feedback request
Hi All, I'm posting to ask how much interest there would be among AFS sites for a file undeletion mechanism in the fileserver. Clearly, AFS users have less apparent need for such a feature given backup volumes, but the semantics are not the same. Thoughts? Matt -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
On Thu, 7 Dec 2006, Matt Benjamin wrote: Hi All, I'm posting to ask how much interest there would be among AFS sites for a file undeletion mechanism in the fileserver. Clearly, AFS users have less apparent need for such a feature given backup volumes, but the semantics are not the same. Thoughts? What would the interface for it be? Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Open to discussion, I think. Hypothetically through a read-only filesystem path (per-volume?), with a purge RPC on (the volume?). Matt Derrick J Brashear wrote: On Thu, 7 Dec 2006, Matt Benjamin wrote: Hi All, I'm posting to ask how much interest there would be among AFS sites for a file undeletion mechanism in the fileserver. Clearly, AFS users have less apparent need for such a feature given backup volumes, but the semantics are not the same. Thoughts? What would the interface for it be? Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
I would believe that what would be desired is a non-permanent delete in the r/w volume in which the file/directory would be marked with a new attribute that means deleted but not reclaimed. Files/directories would be automatically reclaimed as they bump up against their quota. New RPCs would be required to support the undelete operations: * purge all deleted but unclaimed files/dirs * undelete the specified file/dir * list files/dirs that can be undeleted The undelete support should be configurable per volume. A new pioctl would be provided to allow user tools to be implemented that support the list, undelete, and purge operations. Jeffrey Altman Matt Benjamin wrote: Open to discussion, I think. Hypothetically through a read-only filesystem path (per-volume?), with a purge RPC on (the volume?). Matt Derrick J Brashear wrote: On Thu, 7 Dec 2006, Matt Benjamin wrote: Hi All, I'm posting to ask how much interest there would be among AFS sites for a file undeletion mechanism in the fileserver. Clearly, AFS users have less apparent need for such a feature given backup volumes, but the semantics are not the same. Thoughts? What would the interface for it be? Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Undelete support feedback request
On Thursday, December 07, 2006 01:34:50 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: I would believe that what would be desired is a non-permanent delete in the r/w volume in which the file/directory would be marked with a new attribute that means deleted but not reclaimed. Files/directories would be automatically reclaimed as they bump up against their quota. New RPCs would be required to support the undelete operations: * purge all deleted but unclaimed files/dirs * undelete the specified file/dir * list files/dirs that can be undeleted Actually, we're only talking about files here. A directory can't be deleted in the first place unless it's empty, and the undelete operation for an empty directory is the same as the directory creation operation. Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). The mechanism for representing this would not be trivial to design, given requirements like preserving backward-compatibility of the directory format and not allowing the vnode index to grow without bound. Inventing a new volume type would also be problematic, in terms of tracking the relationship between the new volume and the RW, handling mount points correctly, and also because Matt is proposing a new type of clone with different and much more complex semantics. I suspect that the improvement over traditional backup volumes is relatively small, and while it would be a cool feature, I think there are probably others on which the time would be better spent. Buy hey, it's your time, not mine... -- Jeff ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] Undelete support feedback request
The undelete support should be configurable per volume. I think another desirable option to consider (maybe not any first implementation) would be configurable undelete support per directory. At least in my case, a fair amount of the undelete space would be used by various browser and email cache files (yes, one could use, and maybe should use, different volumes for those files, but that is not my current home directory taxonomy). Gary smime.p7s Description: S/MIME cryptographic signature
Re: [OpenAFS] Undelete support feedback request
Isn't undelete an application function? I don't think it belongs in the file system. Are there any other file systems that implement it? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Yes. Jim Rees wrote: Isn't undelete an application function? I don't think it belongs in the file system. Are there any other file systems that implement it? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Sorry, yes, there are other filesystems that implement it. One is Netware's native filesystem. Linux filesystems are now doing so, I found out coincidentally. Jim Rees wrote: Isn't undelete an application function? I don't think it belongs in the file system. Are there any other file systems that implement it? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Jeffrey Hutzelman wrote: On Thursday, December 07, 2006 01:34:50 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: I would believe that what would be desired is a non-permanent delete in the r/w volume in which the file/directory would be marked with a new attribute that means deleted but not reclaimed. Files/directories would be automatically reclaimed as they bump up against their quota. New RPCs would be required to support the undelete operations: * purge all deleted but unclaimed files/dirs * undelete the specified file/dir * list files/dirs that can be undeleted Actually, we're only talking about files here. A directory can't be deleted in the first place unless it's empty, and the undelete operation for an empty directory is the same as the directory creation operation. A delete operation on a directory filled with files that have been deleted but not yet reclaimed needs to be marked with the new attribute. Otherwise, you lose the ability to undelete the files stored within it. Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. I suspect that the improvement over traditional backup volumes is relatively small, and while it would be a cool feature, I think there are probably others on which the time would be better spent. Buy hey, it's your time, not mine... I completely agree that there are many more important things for time to be spent on that are causing users real problems and not just inconveniences. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Jim Rees wrote: Isn't undelete an application function? I don't think it belongs in the file system. Are there any other file systems that implement it? Microsoft Windows as an operating system implements it. The file is moved on disk to a system directory which indexes the names and handles the auto-reclaim when space is required. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
I think it would be more interesting to pursue something like the Shadow Volume Copy Services... http://technet2.microsoft.com/WindowsServer/en/library/2b0d2457-b7d8-42c3-b6c9-59c145b7765f1033.mspx?mfr=true Yea I know, pie in the sky problems. Kidding aside, our upper management is really getting into the kinds of services provided by companies like Xythos: http://www.xythos.com/home/xythos/index.html The services Xythos provides make traditional file systems look outdated. However this is junk to me because it's web based stuff. I'm just an old codger... Hey you kids, get off my lawn! Rodney At 02:21 PM 12/7/2006, Jeffrey Altman wrote: Jeffrey Hutzelman wrote: On Thursday, December 07, 2006 01:34:50 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: I would believe that what would be desired is a non-permanent delete in the r/w volume in which the file/directory would be marked with a new attribute that means deleted but not reclaimed. Files/directories would be automatically reclaimed as they bump up against their quota. New RPCs would be required to support the undelete operations: * purge all deleted but unclaimed files/dirs * undelete the specified file/dir * list files/dirs that can be undeleted Actually, we're only talking about files here. A directory can't be deleted in the first place unless it's empty, and the undelete operation for an empty directory is the same as the directory creation operation. A delete operation on a directory filled with files that have been deleted but not yet reclaimed needs to be marked with the new attribute. Otherwise, you lose the ability to undelete the files stored within it. Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. I suspect that the improvement over traditional backup volumes is relatively small, and while it would be a cool feature, I think there are probably others on which the time would be better spent. Buy hey, it's your time, not mine... I completely agree that there are many more important things for time to be spent on that are causing users real problems and not just inconveniences. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
On Thursday, December 07, 2006 02:21:00 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: Actually, we're only talking about files here. A directory can't be deleted in the first place unless it's empty, and the undelete operation for an empty directory is the same as the directory creation operation. A delete operation on a directory filled with files that have been deleted but not yet reclaimed needs to be marked with the new attribute. Otherwise, you lose the ability to undelete the files stored within it. Good point. Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. ... and how do you pick which one you're undeleting? I mean, I know how to do this at the RPC layer - you just undelete by FID. But what is the UI going to look like? I suspect that the improvement over traditional backup volumes is relatively small, and while it would be a cool feature, I think there are probably others on which the time would be better spent. Buy hey, it's your time, not mine... I completely agree that there are many more important things for time to be spent on that are causing users real problems and not just inconveniences. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
On Thursday, December 07, 2006 02:23:07 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: Jim Rees wrote: Isn't undelete an application function? I don't think it belongs in the file system. Are there any other file systems that implement it? Microsoft Windows as an operating system implements it. The file is moved on disk to a system directory which indexes the names and handles the auto-reclaim when space is required. That works well for local filesystems, and presumably for CIFS. With AFS, Windows can't possibly guess where to put the undelete directory. -- Jeff ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Jeffrey Hutzelman wrote: Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. ... and how do you pick which one you're undeleting? I mean, I know how to do this at the RPC layer - you just undelete by FID. But what is the UI going to look like? You undelete by timestamp and size. If we had multiple stream support than on some OSs there would even be additional metadata available for assisting in the user selection. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Jeffrey Hutzelman wrote: On Thursday, December 07, 2006 02:23:07 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: Jim Rees wrote: Isn't undelete an application function? I don't think it belongs in the file system. Are there any other file systems that implement it? Microsoft Windows as an operating system implements it. The file is moved on disk to a system directory which indexes the names and handles the auto-reclaim when space is required. That works well for local filesystems, and presumably for CIFS. With AFS, Windows can't possibly guess where to put the undelete directory. -- Jeff Which is why it doesn't provide this functionality with the existing client. In Vista, NTFS was extended to support multiple backup copies per file within the file system. So the APIs are there. If we added this functionality to AFS and implemented a native file system interface then Windows could make use of it directly on Vista. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. ... and how do you pick which one you're undeleting? I mean, I know how to do this at the RPC layer - you just undelete by FID. But what is the UI going to look like? Anybody remember VMS? When you replaced a file, it kept the old version around. If you didn't specify which version of a file you wanted, it would default to the current version, but you could just as easily specify the one, say, five versions back. I think you had some control over how many versions of a given file it would keep for you. Deleting a file just meant you didn't want to see version 0 anymore. I think DEC sold a lot of storage because of this... I don't remember what this looked like exactly, but I do remember the UI was so overwhelmingly upper-case that I didn't care for it at all. [BTW, two prominent Jeffreys and a Derek/Derrick pair -- I need pictures to keep you guys straight.] -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / A good pun is its own reword./ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Undelete support feedback request
On Thu, 07 Dec 2006 at 15.04.38 -0500, Todd M. Lewis wrote: ... and how do you pick which one you're undeleting? I mean, I know how to do this at the RPC layer - you just undelete by FID. But what is the UI going to look like? Anybody remember VMS? When you replaced a file, it kept the old version around. If you didn't specify which version of a file you wanted, it would default to the current version, but you could just as easily specify the one, say, five versions back. I think you had some control over how many versions of a given file it would keep for you. Deleting a file just meant you didn't want to see version 0 anymore. I think DEC sold a lot of storage because of this... I don't remember what this looked like exactly, but I do remember the UI was so overwhelmingly upper-case that I didn't care for it at all. $ dir Directory DUA1:[SAC.TEST] FOO.TXT;5 FOO.TXT;4 FOO.TXT;3 FOO.TXT;2 FOO.TXT;1 Total of 5 files. $ purge/keep=3 foo.txt $ set file/version_limit=3 foo.txt $ dir Directory DUA1:[SAC.TEST] FOO.TXT;5 FOO.TXT;4 FOO.TXT;3 Total of 3 files. $ edit foo.txt $ dir Directory DUA1:[SAC.TEST] FOO.TXT;6 FOO.TXT;5 FOO.TXT;4 Total of 3 files. $ del foo.txt; $ dir Directory DUA1:[SAC.TEST] FOO.TXT;5 FOO.TXT;4 Total of 2 files. $ del foo.txt;* $ dir %DIRECT-W-NOFILES, no files found $ -- Sidney CAMMERESI http://www.cheesecake.org/sac/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Undelete support feedback request
On Thu, Dec 07, 2006 at 02:36:08PM -0600, Sidney Cammeresi wrote: On Thu, 07 Dec 2006 at 15.04.38 -0500, Todd M. Lewis wrote: ... and how do you pick which one you're undeleting? I mean, I know how to do this at the RPC layer - you just undelete by FID. But what is the UI going to look like? Anybody remember VMS? When you replaced a file, it kept the old version around. If you didn't specify which version of a file you wanted, it would default to the current version, but you could just as easily specify the one, say, five versions back. I think you had some control over how many versions of a given file it would keep for you. Deleting a file just meant you didn't want to see version 0 anymore. I think DEC sold a lot of storage because of this... You could put a limit on how many versions were kept for each file and you could arbitrarily delete any version, all versions or all versions older than xxx. I found it usefule a few times, but not often. jerry I don't remember what this looked like exactly, but I do remember the UI was so overwhelmingly upper-case that I didn't care for it at all. $ dir Directory DUA1:[SAC.TEST] FOO.TXT;5 FOO.TXT;4 FOO.TXT;3 FOO.TXT;2 FOO.TXT;1 Total of 5 files. $ purge/keep=3 foo.txt $ set file/version_limit=3 foo.txt $ dir Directory DUA1:[SAC.TEST] FOO.TXT;5 FOO.TXT;4 FOO.TXT;3 Total of 3 files. $ edit foo.txt $ dir Directory DUA1:[SAC.TEST] FOO.TXT;6 FOO.TXT;5 FOO.TXT;4 Total of 3 files. $ del foo.txt; $ dir Directory DUA1:[SAC.TEST] FOO.TXT;5 FOO.TXT;4 Total of 2 files. $ del foo.txt;* $ dir %DIRECT-W-NOFILES, no files found $ -- Sidney CAMMERESI http://www.cheesecake.org/sac/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Undelete support feedback request
Sidney Cammeresi [EMAIL PROTECTED] posted the VMS way. Not that I'm advocating this is the right way (let alone have code that implements this), but here's how the same things could look in Unix: $ ls -F foo.txt $ ls foo.txt/* foo.txt/1 foo.txt/2 foo.txt/3 foo.txt/4 foo.txt/5 $ fs purge foo.txt -keep 3 $ fs set_version_limit 3 foo.txt $ ls foo.txt/* foo.txt/3 foo.txt/4 foo.txt/5 $ echo hi foo.txt $ ls foo.txt/* foo.txt/4 foo.txt/5 foo.txt/6 $ rm foo.txt $ ls foo.txt foo.txt $ ls foo.txt/* foo.txt/4 foo.txt/5 $ rm foo.txt/* $ ls foo.txt ls: foo.txt: No such file or directory $ At least there's no upper-case this way. -Marcus ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Undelete support feedback request
On Thursday, December 07, 2006 05:38:07 PM -0500 Marcus Watts [EMAIL PROTECTED] wrote: Sidney Cammeresi [EMAIL PROTECTED] posted the VMS way. Not that I'm advocating this is the right way (let alone have code that implements this), but here's how the same things could look in Unix: $ ls -F foo.txt $ ls foo.txt/* foo.txt/1 foo.txt/2 foo.txt/3 foo.txt/4 foo.txt/5 That's not really tenable. Some operating systems do have objects that look like files from some angles and directories from others, but others have VFS layers that don't really allow for this. I very much doubt that the linux dentry cache can handle an object which claims to be a file but has children, and even if it did, you'd have an interesting time dealing with files which have multiple links, since directories may not have multiple aliases in the dentry cache. Now, replace 'ls foo.txt/*' with 'fs listdeleted foo.txt', and you're fine. At least there's no upper-case this way. There's nothing inherently upper-case about VMS. It has a case-insensitive filesystem, and defaults to listing filenames in upper case. You'd see lots of upper-case in your example, too, if the file were named FOO.TXT. -- Jeff ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
I second Rodney's suggestion. Disclaimer: his office is next to mine ;) Being able to have snapshots of a volume or multiple backups of a volume from different times. I think the simplest approach would be to clone a volume and give a new but predictable name like vol.backup1 or vol.b20061207 I don't have a specific need for this at the moment, but it's in my nice to have category. Jason Rodney M Dyer wrote: I think it would be more interesting to pursue something like the Shadow Volume Copy Services... http://technet2.microsoft.com/WindowsServer/en/library/2b0d2457-b7d8-42c3-b6c9-59c145b7765f1033.mspx?mfr=true Yea I know, pie in the sky problems. Kidding aside, our upper management is really getting into the kinds of services provided by companies like Xythos: http://www.xythos.com/home/xythos/index.html The services Xythos provides make traditional file systems look outdated. However this is junk to me because it's web based stuff. I'm just an old codger... Hey you kids, get off my lawn! Rodney At 02:21 PM 12/7/2006, Jeffrey Altman wrote: Jeffrey Hutzelman wrote: On Thursday, December 07, 2006 01:34:50 PM -0500 Jeffrey Altman [EMAIL PROTECTED] wrote: I would believe that what would be desired is a non-permanent delete in the r/w volume in which the file/directory would be marked with a new attribute that means deleted but not reclaimed. Files/directories would be automatically reclaimed as they bump up against their quota. New RPCs would be required to support the undelete operations: * purge all deleted but unclaimed files/dirs * undelete the specified file/dir * list files/dirs that can be undeleted Actually, we're only talking about files here. A directory can't be deleted in the first place unless it's empty, and the undelete operation for an empty directory is the same as the directory creation operation. A delete operation on a directory filled with files that have been deleted but not yet reclaimed needs to be marked with the new attribute. Otherwise, you lose the ability to undelete the files stored within it. Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. I suspect that the improvement over traditional backup volumes is relatively small, and while it would be a cool feature, I think there are probably others on which the time would be better spent. Buy hey, it's your time, not mine... I completely agree that there are many more important things for time to be spent on that are causing users real problems and not just inconveniences. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] How to store files in OpenAFS
Hi. I have installed OpenAFS 1.4.2 on Fedora 5 using the downloaded rpms. I'm able to create partition and volumes(root.afs, root.cell, afsdoc). Whenever I start openafs client, I'm able to see the directory for cell created under /afs as /afs/mypc.co.in But when I try to list the contents of the cell, it is not allowing me to access the same. # ls /afs/mypc.co.in/ ls: /afs/mypc.co.in/: Permission denied Further, following commands are failing. # fs setacl /afs system:anyuser rl fs:'/afs': Connection timed out # fs setacl /afs/mypc.co.in system:anyuser rl fs: You don't have the required access rights on '/afs/mypc.co.in' # fs mkmount /afs/mypc.co.in afsdoc fs: cell dynroot not in /usr/vice/etc/CellServDB # fs examine /afs fs:'/afs': Connection timed out # fs examine /afs/mypc.co.in fs: You don't have the required access rights on '/afs/mypc.co.in' How to get access rights to the cell? Further, how one can store/retrieve a file from OpenAFS? Thanks and Regards, Shailesh Joshi ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
