Re: [OpenAFS] Current Limits of OpenAfs ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adding to that, I'd suggest reading the slides from Alistair Ferguson's keynote at the 2008 AFS workshop. The current client/server ratio (2000/1, going to 5000/1?) and configured callback's per file server (4 million?) in one Morgan Stanley enviornment are mentioned, IIRC. Matt http://workshop.openafs.org/afsbpw08/wed_keynote.html Derrick Brashear wrote: >> Can anyone tell me how to calculate the memory requirement for each client >> on a server ? > > Not without more information. The state information is stored per > callback, which is one per file/directory in a writable volume, and > one per entire readonly volume, so without knowing what the client's > utilization will be, I can't say. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJaOQwJiSUUSaRdSURCCHzAJ9BjcKom2o0qbo/rAtysd6w1CcsYQCfc2fH 61yzVdF8fEpqQd17C+jjsJU= =xsG6 -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Um: sorry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I don't know how that was possible, but, my apologies. Matt Matt Benjamin wrote: - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJY+MkJiSUUSaRdSURCGCLAJoCr5VRwqooJJZ1un5esQftI3yzcgCgl5xD AWOL479VqFPQeVKJuuEkNVE= =VSyT -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Deadline- Jan 9! CFP: 2009 OpenAFS & Kerberos Best Practices Workshop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Esther (cc workshop), I submitted the following information responding to the call for papers for the afsbpw2009--my submission failed with runtime error (hopefully not to do with OpenAFS :). I'm supplying the information to you by email, in hopes that will count as submission within the deadline. Matt Benjamin (734) 216-5309 m...@linuxbox.com Extended Callback Information: Results and Implications This talk will review the proposed Extended Callback Information protocol extension, which has now been implemented for a variety of platforms in OpenAFS. Implications for cache consistency, protocol load, and overall system complexity will be discussed. Performance and correctness results, along with various implementation details, of the current OpenAFS implementation will be presented. ** Error details: Warning: session_start() [function.session-start]: open(D:\WINDOWS\Temp\php\upload\sess_54686qv1r996h2dnlfak5fijm7, O_RDWR) failed: No such file or directory (2) in \\afs\grand.central.org\www\workshop.openafs.org\legacy\afsbpw09\email.php on line 37 Thank you! Your talk has been submitted. Return to workshop home page Warning: Unknown: open(D:\WINDOWS\Temp\php\upload\sess_54686qv1r996h2dnlfak5fijm7, O_RDWR) failed: No such file or directory (2) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (D:\WINDOWS\Temp\php\upload) in Unknown on line 0 - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJY+GhJiSUUSaRdSURCAGOAKCBt/G9lmj62/EJssWxcHtnClYDnwCfTLWD twpHpc7bVKo+5rfBxU/WgBk= =7Nhl -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] About AFS performance over WAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm personally interested in SCTP, but having followed the tsvwg and other development channels for more than a year, I'm not convinced that SCTP is going to provide an immediate term viable bulk transport, though it may turn out to be a brilliant choice in the medium-longer term, especially if you like FreeBSD. Some of the issues include not just platform coverage, but also interoperability, checksum offload (or proposal by some folks to remove the crc32c checksum requirement) [though that is CPU-specific, cf SSE 4.2 on Intel], and performance properties of (the Linux) SCTP driver, or so it appears to me. Matt Derrick Brashear wrote: > On Wed, Dec 3, 2008 at 11:10 PM, Dale Ghent <[EMAIL PROTECTED]> wrote: >> On Dec 1, 2008, at 4:24 AM, Rainer Toebbicke wrote: >> >>> With unlimited development resources AFS would deserve a better suited >>> protocol than TCP, in practice with a little more realism my gut feeling is >>> that at least some more brain should be devoted to improving plain RX rather >>> than betting on another horse. I occasionally tried over the past years, >>> with some improvements that Hartmut tested as well, but my brain being what >>> it is and the matter relatively complicated results remain modest. >> Given this, what are your thoughts on STCP and whether it would be useful in >> this arena? > > SCTP. At this point it may have critical mass of platforms we support > and thus be a viable option. That I know of the Windows options for it > are slim. There is a MacOS version from KAME, but I don't know the > licensing details. Since it doesn't ship with the OS (and in any case > where it doesn't) that's a practical consideration. > ___ > 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJN7djJiSUUSaRdSURCPF8AJ9AWX8gKvbgMJanuQ4flJ4F3kXH+wCdFjvo 6DX2JDMzznMj3YFlLwb0IrE= =GYZh -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Communication errors on volume operations
Hi Bryn, Is this a DAFS file server? If so, then probably a known behavior, although I'm not certain it should be seen in 1.5.55 (Tom?) As you imply, the volume can in that case be salvaged and then brought on-line (bos salvage -forceDAFS). Matt Bryn Divey wrote: Hi all, I've compiled OpenAFS 1.5.55 to debs to check out the read/write disconnected operation stuff, and I'm getting errors on various volume operations. For example: [EMAIL PROTECTED]:~$ vos create ubuntu-dfs.hostname.com /vicepa root.cell -cell hostname.com Failed to end the transaction on the volume root.cell 536870918 Possible communication failure Error in vos create command. Possible communication failure The new volume needs to be salvaged before anything can be done with it. I get a similar error on releasing a volume. What could possibly be causing this problem? Is it merely a known, in-development bug? Regards, Bryn Divey ___ 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] Re: FreeBSD port crashes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Karsten, I can reproduce this--by attempting to start FreeBSD's afsd in a cell without a root.afs volume. The client needs to deal in a more civilized way in this case (it is going to fail to mount /afs, etc, in any case), but for now, create a root.afs? Matt Karsten Thygesen wrote: > Hi > > I just wish to add some more details.. I have now tried to build 1.4.8 > from source and it gave me the exact same result :-( Well - as I said, > I'm eager, so I tried the lastest 1.5 and it builded without problems, > but as soon as I try to load afsd (the kernel module loads fine), it > scans the empty cache diretory and the crashes, bringing the OS to a halt. > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJNGQ3JiSUUSaRdSURCFROAJ9rDqt6+ZfzcyV2VVV2j+zfzafvPgCePBFx 8/3lAIwnR8UVw2nomY3fEcM= =i4Dp -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Proto-TAC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ok, I've re-read this, and I think it's a smaller question than I thought. I did not intend to call into question the funding plans that have been made for the OpenAFS foundation, to the degree I understand them. I probably expressed myself badly. What I was trying to say, simply, was that I'd suggest that the number of seats on the TAC needs to fit the available community personnel too, not solely the number of corporate contributors, especially if, hypothetically, there were an insufficient number of such corporate sponsors at the beginning, or from time to time. I'm happy to have those sponsors there, and supportive of it. Matt Russ Allbery wrote: > Matt Benjamin <[EMAIL PROTECTED]> writes: > > I don't understand why you think this is a regression from the current > situation. Currently, the only large projects that happen at all are the > ones that are funded by someone. This system opens the possibility of > using contributions more collectively for projects of benefit to the whole > community instead of only doing large projects that can be funded entirely > by one or two organizations. It therefore also adds oversight so that > people can have a say in how that money is being spent. > > Currently, we have exactly the situation that you say that is problematic, > except to an even stronger degree because we have no collective funds to > speak of and are essentially entirely dependent on whatever someone with > funding implements. > > What role for the community do you perceive exists now which would become > secondary under this model? > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJE0jUJiSUUSaRdSURCOZ1AJwPRcvUuBKGpJnvNdrzlA1+FYuVfACfTc4E vH1R6eHuSFeHFvFLZ7gwFvM= =cAlH -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Proto-TAC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff, Jeffrey Altman wrote: > The most important aspect of the TAC is the use of the TAC in > combination with OpenAFS membership to generate funds that > can be used to support the infrastructure and processes of the > organization. I've gathered this, but I don't think it is necessarily understood by the large part of the community as yet. (Apologies if that's not the case.) The formulation seems quite problematic to me personally, as I've stated a number of times in public and private discussion, because as articulated below, it appears make the community and community developers secondary to (as yet unnamed, though that's not the concern) investors. (I actually think that runs counter to the spirit under which IBM originally released the OpenAFS code, though of course I've had no discussion with any IBM employee regarding that.) > > Organizations that write OpenAFS a check for $?0,000 or more receive a > guaranteed seat on the TAC. The number of organizations that do so > determine the size of the TAC. The TAC would contain three times the > number of seats as the number of largest contributors. (I think $?0,000 > is $49,500 as that number has been well received by several large > organizations but it is still up for debate.) I've raised some issues with the point that the number of TAC seats can be indexed solely to the number of new corporate sponsors, that's the point of my above remark. > > Organizations that write a check for at least $5,000 but less than > $?0,000 fall into the second tier. These organizations are not > guaranteed a seat at any particular period of time. Instead, the > available seats are rotated among the members of the group. > > Finally, eligible individuals from the community who have demonstrated > sufficient participation (as measured by karma points which can include > individual contributions of money or code or assistance to other > community members) will elect their representatives. The basic notion seems reasonable. As I've stated in conversation, I'm uncertain these mechanisms are appropriately tuned, as yet, though. > > If in the case that there would be an even number of representatives > the individuals get an extra seat. The size of the TAC can change > from year to year based upon the number of contributing organizations. It should be equally important how many active, appropriately skilled developers (and helpful others) are available, shouldn't it? > > In order to move the TAC forward, OpenAFS needs to begin soliciting > contributions. While Usenix is willing to accept the checks on our > behalf, organizations have indicated that until there is a legal > Foundation whose membership they can purchase, there is no mechanism > by which a check can be written. Hence in my opinion the Foundation > and the Board of Directors must come first. > Thanks, 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJExpVJiSUUSaRdSURCD7FAJoDqtYSW7NvJfhI1C7MyB/StGHa2gCdF30G FEDvOSCjueIJoGlhS3Ms/ZE= =vgpD -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Proto-TAC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Jeff, Well, Evan is certainly a member of the community. I don't think he meant to step on any toes. I intended to suggest only what Derrick's comments summarized, not new mechanisms to submit architecture proposals, so I'll leave it there. An new mechanism I'd benefit from would be scheduled openafs conference developer meetings between hackathons. I think that would help us make more steady progress on tasks like libosi integration. That certainly doesn't require a TAC, but it would probably require a bit of time commitment from some subset of active developers to be useful. Matt Jeffrey Altman wrote: > Speaking as a gatekeeper: > > If there are AFS3 protocol changes that you or your colleagues would > like to propose, write them up in the form of an Internet Draft and > submit them to AFS3 Standardization. > > If there are architectural changes you would like to propose for > the OpenAFS code base, write up an architectural design document > and send it to [EMAIL PROTECTED] so that the community > can discuss it and the gatekeepers can provide feedback. > > The technical advisory council will be a subset of the community > that will speak for the community. However, it will never replace > the community. Until it exists, I recommend using the mechanisms > that are already in place. > > Jeffrey Altman - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJEw7LJiSUUSaRdSURCI3GAJ9GaQ98em7tWF5K1V/YnrXVcL9UVQCgg5/V mxXm+P9gNDmQ9y3yb6Mec9c= =wRsJ -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenAFS TAC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi All, There hasn't been much discussion that I've noticed on-list regarding support for/objections to the proposed technical advisory council mentioned in Derrick's document. There have been a number of such discussions with a subset of active OpenAFS developers participating, and to my knowledge, there is generally consensus (I include myself) that we would support the concept in some form, and would plan to participate. I think there are some open issues in the foundation space relating to the TAC, and final details of what will really exist, and exactly when the foundation will begin to exist formally. With regard to the TAC specifically, there seems to be an open question about how many seats it will have, eligibility/karma required to sit, and how the number of seats allocated to community members (which I believe would include all people I know to be probably interested in participating) would relate to seats allocated to corporate or sponsor members. So I'm highlighting those items for further discussion. I'd say for myself that if this is the way the community plans to move forward, that it might not be a bad idea for the community to simply get started organizing an informal proto-TAC and see what issues it's going to present, and what opportunities it may offer. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJEKmOJiSUUSaRdSURCC7kAJ92VoLdSs24o+8oG7Lymlx9XQRySwCdGclf rnR10MrAJTqcl6BG4axM1Ww= =lg7T -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
rotation/term limits: Was: [OpenAFS] Foundation Plan redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think I'm with Felix here. I'm not completely sure whether term limits do or don't help in the abstract. It felt to me the last time I thought through this that diversity or size or balance of the body might be equally important factors. Before the current drafts were published, I took the position that perhaps there was nothing intrinsically wrong with the original gatekeeper role, and that we simply needed to be recruiting and developing more of them. That's not how things are moving, though. In the proposal, there are at least three different leadership bodies, board, TAC, project leaders in the organization structure Derrick has proposed. There will no longer be gatekeepers or elders, at least in name. Presumably rotation or other restrictions might be more important for some of the proposed bodies than others. It seems important to really understand (or discuss more explicitly) the kinds of decisions or activities the individuals in each of those bodies will need to perform, and look at how exclusivity and rotation/non-rotation would play into those. Matt Felix Frank wrote: >>> How long can one obtain >>> as a gatekeeper or board member? Is there a term limit (a desirable >>> thing, IMHO, as it forces an organization to develop new leaders rather >>> than having the same faces in the same places)? > But then, bearing that in mind, it's unclear to me as well how much good > term limits could actually do towards the goal of encouraging new people > to take actual responsibility. But too strict a seperation of > responsibilities would probably lead to the decapitated body you described. > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCdvPJiSUUSaRdSURCPReAJ9es0oIpcFevqhhk28uCzeEOzosVACfco+S 74NMNJiZqrA+dXCjBvyZyzY= =2nCo -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Build samba 3.2.2 with openafs 1.4.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dude, The CHANGES file in the source for openssl-0.98g has this to say, I draw your attention to paragraph 2: There are also macros that enable and disable the support of old des functions altogether. Those are OPENSSL_ENABLE_OLD_DES_SUPPORT and OPENSSL_DISABLE_OLD_DES_SUPPORT. If none or both of those are defined, the default will apply: to support the old des routines. In either case, one must include openssl/des.h to get the correct definitions. Do not try to just include openssl/des_old.h, that won't work. good luck, Matt Gémes Géza wrote: > Jeffrey Altman írta: >> Gémes Géza wrote: >> >>> Derrick Brashear írta: >>> >> >>>>> Compiling smbd/server.c >>>>> Linking bin/smbd >>>>> bin/smbd.a(afs.o): In function `afs_createtoken': >>>>> afs.c:(.text+0x2b7): undefined reference to `DES_key_sched' >>>>> afs.c:(.text+0x2e9): undefined reference to `DES_pcbc_encrypt' >>>>> >>>>> >>>> Either the linker is failing to try to link the openssl libraries or >>>> you have a version which is too new. >>>> >>>> >>> My openssl version is 0.9.8g >>> >>> I've run the make process under strace as well, but even with the -f >>> option I couldn't see anything relevant. >>> >> Look at the headers for openssl. You will see that DES_ symbols are >> macros. I think you want one of the OLD DES options. >> >> >> >> > Hi, > > After some googling I've gave up could you send me some pointers about > using the old des options including des_old.h doesn't seem to work. > > Thanks in advance > > Geza - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIxATWJiSUUSaRdSURCB5ZAJ9wQ3A2nu3wcw/0wLqMfXRTep8qPACbBNb5 s05wIse52skU24/41LV+IEg= =N9CT -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] On contributor agreements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This assessment seems pretty sound. It's still the case that some contributors have preferred to contribute under BSD terms, and might continue to do so. Do we have a mechanism in place to know under what terms a specific non-founding contribution has been made? Derrick Brashear wrote: >> > While I personally would like to see it easier to relicense the > codebase to BSD, I believe this is not realistic as it would > require all contributors to agree or have their contributions > discarded and reimplemented... and more importantly I don't think > there's much danger of IBM's lawyers vetting and agreeing to it. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwVk+JiSUUSaRdSURCDjYAKCNJ6dTVWukXwnNVPNEoVmUA+TDAQCfd83k DUS+S4dKhaKMeW6Dtf8IqKc= =RAwT -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] vos release fails -- bandwidth too low?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I don't know if it will resolve your issue, but I strongly suggest TCP for the OpenVPN transport. Matt Chaz Chandler wrote: > Background: > We've implemented a bridged OpenVPN multi-site network via UDP. The vpn has > not been specifically optimized for bandwidth, but that is probably a > discussion for another forum. We are currently seeing about 26KBps sustained > across the links. > Our OpenAFS trial setup has two file servers, one with an RW volume and both > with RO volumes of the RW one. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIu0TrJiSUUSaRdSURCH44AJwMYuXBbK7Cbh0M58pZSxmNrVQ6PwCfbY8P V6E7rapiC/X/xQtltM+NUwM= =ucM9 -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: [grand.central.org #89557] Re: next clone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey Altman wrote: | Matt: | | You can update any ticket in RT by sending e-mail to | [EMAIL PROTECTED] with | | [grand.central.org #89557] | | anywhere in the subject line. Oh, duh. Thanks. Replace the rx clones ticket number with | another ticket | number if you wish to update another ticket. That's not how it should work. Please make a note to fix this the right way at some time when it doesn't present in an inconvenience, deadlines, etc. | | In conversations with Derrick regarding this work, Derrick has pointed | out that | an assumption has been made that I have performed a thorough architectural | review of the RX library to determine what must be done to safely implement | clones. I have not done such a review. My original post creating 89557 | was | simply a rough sketch of an idea. My review of your work pointed out | specific | issues that I had uncovered. However, I did not perform an examination of | each and every member of the rx_connection and rx_call data structure to | determine what should be done with it in the case of cloning. It was | my hope | that Tom would have had more time on his plate to review the design and | implementation and point out additional places where issues would be found. I can probably get some feedback from Marcus, as well, but I see the issue here. I'm not pushing anyone. | | Thank you for your continued work on this project. I will review the code | when I have time. I am currently under several deadlines related to the | native file system client so that it can be ready for testing at | Microsoft next | week. | | Jeffrey Altman | - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIm2gjJiSUUSaRdSURCFZ/AJ4/kG+IIpzaWJ1tFyf15ZepBojX2wCfRsh7 UyjhwARdWcNVGzGWwlIaUPo= =i2oK -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] An open letter from the OpenAFS Council of Elders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenAFS has been moving towards this goal since at least 2004. I'm very glad it's now possible and still seems desirable to move forward. We will all benefit. Matt Derrick J Brashear wrote: | Since OpenAFS began its life as an open source project seven and a half - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIJ5sXJiSUUSaRdSURCH6tAJ9N6tt9wfiitRGv0Y9ncm7jHyjvjACcCL2S 2+6Asc/nF9DM773TY6pB378= =lOdE -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: [OpenAFS-devel] An open letter from the OpenAFS Council of Elders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Troy, Your wish is granted. Derrick is working on migration of the CVS repository to git. Matt Troy Benjegerdes wrote: | | We don't need to re-invent a better source control system.. Bitkeeper, | Git, darcs, monotone, mercurial have all already tried that. I would | just like openafs to pick one and go with 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIJ0OeJiSUUSaRdSURCLh0AKCKREc1Hsi09oXFwTgdRYLqHlGykACeKs9E uW0QjhwZIgIE06KeD1sCNu0= =IoHQ -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Fedora kernel builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 An nnpfs-style approach is not ruled out, however. Matt Jeffrey Altman wrote: | Derek Atkins wrote: | |> Then again I've also just considered a GPL module that wraps all the |> GPL-only APIs and just re-exports them. Hey, THAT module is GPL! ;) |> This whole GPL-only thing is just stupid. | | Read http://kerneltrap.org/Linux/NDISwrapper_and_the_GPL | - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3UbEJiSUUSaRdSURCPetAJ43XckrZD8HCs93K2PCgqlEdTDVJACfXs7P blH0YVlYRf+7M+H1MJ0mJqY= =WgwU -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] File systems on Linux, again.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 woot, chas :) chas williams - CONTRACTOR wrote: > no i dont think rx locking is the problem. the rx locking is > actually pretty good. i had tracked this down with fstrace > at one point but i seem to have lost the trace at the moment. > i will dig around and see if i can find it. > > In message <[EMAIL PROTECTED]>,Matt Benjamin writes: > Hey, Chas, > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUFNgJiSUUSaRdSURCH7/AJ9eTtSta1JCYEcL4jt2kaPH4rm25QCePpXS 8ozxvvFRngC1EMZz1vXY/0E= =koC6 -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] File systems on Linux, again.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, Chas, Sorry to bug. I've been looking at this, tangentially, because I've been working with bypassing dcache/memcache, writing direct into page cache. Pretty far along on that side of things. Is rx locking so coarse that in general only one read makes progress even independent of the cache--to your knowledge? Matt chas williams - CONTRACTOR wrote: > In message <[EMAIL PROTECTED] > ia.net>,"Jerry Normandin" writes: >> write performance is actually impressive. file creation and deletion >> are very slow on afs. > > because writing is easier than reading. the afs cache manager can > group the outgoing writes together and send them in a single message. > while the cache manager has readahead it doesnt work because the afs > global locks blocks any progress the readahead thread might make. > ___ > 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUEJRJiSUUSaRdSURCA2lAJ4p19x8OH8y2cYO3WERwapwdZ9gYwCffFeR t96QUFYv5yHK6wlFTbn9TSE= =BAnD -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Strange access problems on one client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think Derrick was being careful when he said it a) fixed the issue and b) was harmless. Matt Marc Dionne wrote: > Carson Gaspar wrote: >> Hans-Werner Paulsen wrote: >>> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: >> >>>> +else if (hval >= 1<<31) >> >>> this patch is fine for architectures where the size of "unsigned long" >>> is 4 bytes. But on the x86_64 architecture this will not work, because >>> the size is 8 bytes. One can use "unsigned int". >> >> Ummm... no. This whole thing is way too fragile. If you care about how >> many bits the variable has, you MUST use something like uint32_t. Or >> you can not care, and use sizeof() to generate your comparison. But >> you MUST NOT use "int" or "long" and hard-code bit shifts. > > Sure enough - with the original patch I was trying to confirm that this > was indeed the issue, and didn't try to be generic. > > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDuGCJiSUUSaRdSURCC7EAJ9QSM14weKgsjT0EZcUnS9O0cSCUACgj+mb P7FrrFgD3q4cp6GKWKBqRR0= =LHDI -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] AES Support ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher, You are correct, the service principal is canonically afs-k5/[EMAIL PROTECTED] Matt Christopher D. Clausen wrote: > John Hascall <[EMAIL PROTECTED]> wrote: > > I'm assuming that something like afs-k5/[EMAIL PROTECTED] will work, as I > already have multiple AFS cells using the same Kerberos realm. > > < > > ___ > 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+l+IJiSUUSaRdSURCJ73AJ4lDMRCxoH/P77Ov0JlKMHlH+h4DwCeICxD ltGo0FR6Jgb+sTy1gAwfsnE= =x6Gr -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Disconnected OpenAFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Derrick, We have communicated privately about this, but I didn't think there was anything secret in what I wrote, after having open discussion about this with Simon at the openafs workshop; I apologize, to you and Simon, if I misunderstood that. Matt Derrick Brashear wrote: > > > On 9/23/07, *Matt Benjamin* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > As I understand it, and I was in a discussion about this last week: If > the gatekeepers were willing and able to establish a more collaborative > project around this, there are more developers willing to work on > disconnected merge (including one of the original authors). > > > Since someone else outed Simon already I don't feel bad doing so; His > name was communicated privately the last time I was asked and so far > only he has offered any results, so I'm curious who the other developers > might be, and if they talked to him yet. > > You don't really need us for this at all though if it helps I would be > happy to coordinate or help set benchmarks, but only the benchmarks will > likely ever see releases, and (unless you have questions about how the > code works that I can help with, which I will) there's nothing much for > gatekeepers to do other than vet and integrate those benchmarks. > > Derrick > speaking only for myself > > > > > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9sGWJiSUUSaRdSURCOOaAJ9S2+gwueKlyLQq4A5KqbS1IaXt9gCfV7LQ ACn8NFEHAh9O8bBnSyL+SHk= =n+O9 -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Disconnected OpenAFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As I understand it, and I was in a discussion about this last week: If the gatekeepers were willing and able to establish a more collaborative project around this, there are more developers willing to work on disconnected merge (including one of the original authors). Matt Jason Edgecombe wrote: > > See > http://workshop.openafs.org/afsbpw07/talks/openafs_roadmap_BPW_2007.pdf > - page 6 > > The OpenAfs project is always looking for more support in the form of > volunteers or money. > > If anyone has any more info, please speak up. > > Sincerely, > Jason > ___ > 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9rW0JiSUUSaRdSURCHwGAJ0QtB7e17jRO9YAQFRIyWmdAmb0YACfSD26 XLurf9DZeTbc9Qm1lYr36Sc= =/H/2 -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Disconnected OpenAFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey Altman wrote: > > Some work has been done on integrating UNIX read-only disconnected mode > onto the CVS HEAD. Since Simon Wilkinson has apparently made progress with merging the CITI disconnected AFS patches with OpenAFS, I thought that was the direction for disconnected operation? Are you talking about the same effort? > > The hard part about disconnected operation is not what happens in the > cache manager but the user interface that must go with it so that users > can determine what data should be available in the cache when the client > goes off-line and how collisions should be resolved when the client is > back on-line and the data on the server has been changed. That issue is addressed in the CITI disconnected AFS, at least for the command line. > > There are also issues surrounding file locks that must be resolved. One has to start somewhere... 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9rR3JiSUUSaRdSURCNCcAJ4rCEgFrsuaOkBQjX4qw4VtuLUBBgCfVSSr f6n7+jeXlCb6Qz3irkUG6DI= =AKlS -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] New Server, Journaling FS, and Windows Client...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, With a namei fileserver (which you're necessarily running on Linux), you can use ext3, or XFS, or reiserfs, or other file systems for vice partitions. It's commonly done. You can even get around /vicepXXX being partitions, if you want. Matt David Sonenberg wrote: > Now that I've got my new database/fileserver up and running, I have a > few questions... > > First off does /vicepa need to be on a non-journaling filesystem? The > documentation said to use ext2, but if it's not a requirement, I'd like > to covert it to ext3 with journaling. > - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe+EXJiSUUSaRdSURCOeiAJ9Th8WPiZAtT/eO2NVtzwDn3taPXwCfZxAF d8az45oLNlwS6LUuaR+jwhs= =JHZV -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] openafs performance in an internet-scale traffic environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Richard, OpenAFS definitely has been used in (some variant of) this way, with at least some success. You might find some reference to such on the openafs-info list from a few years go. I have not seen formal discussion of the results. Matt Richard Human wrote: > Hi all, > So we're looking at open-afs. We are thinking of a situation where we > have a cell of 2+ servers on the back-end with our data spread over a > number of volumes, that we can move around. This takes care of the > scalability issue. For redundancy we would investigate the volume > replication feature. > > I've read the success stories on the website. However, most of these > cases talk about scenarios where there are 100s of clients accessing an > afs cell that is holding users' home directories. In our scenario we > will have 5 to 10 (max) clients, but performing 5k - 10K operations > across the whole cell per second. > > My question is simple: has/can open-afs be used in a situation like > this? If it has/can then I will go on with building a test platform and > testing it in our environment. But before doing that I'd like to know if > I'm on the right track. > > Many thanks > Richard Human > > ___ > 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3JCgJiSUUSaRdSURCBYVAKCGbK1Mxthb6fPVPvNdxFuvkseDxACdGJwX nCwGMH5S/szAOMRitz8mAas= =3Msv -END PGP SIGNATURE- ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] set client to refuse byte-range locks?
Adam, There is work ongoing to improve the Unix-like clients' locking support. At the moment, I don't think OpenAFS 1.4 or 1.5 have an easy way to do (either notion you suggested of ) what you want, but, it was easy to hack up a patch to do it (the first suggestion, I didn't want to think about the second one). Matt Adam Megacz wrote: Is there any way to set the Linux OpenAFS client to simply refuse all requests for byte-range locks? Barring that, is there a way to find out which file the message "afs: byte-range lock/unlock ignored; make sure no one else is running this program" refers to? - a -- 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
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
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
[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
[OpenAFS] Re: [OpenAFS-win32-devel] OpenAFS vs Vista
Jeff, I recall seeting the IFS working (by some definition of "working") on Eric JW's workstation in 2005. What specifically are the missing features that must be implemented to complete the work? Matt Jeffrey Altman wrote: The long term solution is clear. The OpenAFS community needs to move away from the SMB Gateway model and replace it with a native Network Provider / File System Filter model. Completing this work in such a way that it is portable across Windows 2000 SP4 through Vista and works on both 32-bit and 64-bit operating systems is going to be time consuming and expensive. I hired a Windows file system and kernel driver developer to review the work that has already been done and help design an architecture that can support all of the required platforms for the next ten years. We believe that this work can be accomplished over a period of ten months provided that the necessary financial resources ($250,000 - $300,000) can be acquired. The long term benefits of getting rid of the SMB gateway are: (1) the use of the Microsoft Loopback Adapter will no longer be required (2) all of the problems associated with the CIFS client timeout issues will be removed. this will not only improve performance but will solve all of the "delayed write" and "network path no longer available" errors. (3) performance gains. There is significant time delays and CPU load added to each transaction as a result of the CIFS client and SMB server both involving the SMB/NetBIOS/TCP/IP stack. If your organization is in a position to assist us in financing this work, please contact me off-list. Jeffrey Altman OpenAFS Gatekeeper/Elder ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: why afs backup is so poorly supported
Cool as the transactional piece would be, iirc from our discussion in 2004, putting a postgresql behind every fileserver sounds kind of heavyweight, doesn't it? Plus, is there a difference between transactional metadata updates and transactional file data updates? Matt Marcus Watts wrote: Jeffrey Hutzelman <[EMAIL PROTECTED]> replied: ... It's an interesting idea, though probably more suitable for discussion on openafs-devel than in this forum. To handle StoreData, you'd need the ability to update only part of a blob. Also, how efficiently are large blobs handled even by those databases that support them? That most likely depends on the database & API. At a quick glance, the command line tool for postgresql only imports & exports to "a local file" (which has interesting similarities to the origins of AFS). The libpq C interface to postgresql supports read, write, lseek from/to the server, much like regular file access. The internals of postgresql implement blobs as chunks in a special table which can be randomly accessed. Blobs can be up to 2G in size. There are also "toasted" objects, which probably aren't as useful. I'm afraid to ask if one can toast blobs. My recollection is that oracle has some sort of chunk-wise access to blobs. I assume other db systems (db2, etc.) have similar functions, at least if they intend to implement the "l" in blob. One interesting limitation with blobs may have to do with rollback segment size. I know that's an issue with oracle, not sure about postgresql. The basic problem is that if you update 2G of stuff, you might not be able to do it as one atomic transaction. Probably you shouldn't want to in any case, but it might spoil chas's vision of atomic commits. -Marcus ___ 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] Supported enctypes in OpenAFS 1.4.x
Actually, rxk5 provides the kernel crypto (using k5ssl, a kerberos5 library implementation by Marcus). In recent versions, it can apparently do the usermod crypto, too. It's true we've been working with the (user-mode, native) Linux cache manager only so far, but theoretically, the only required changes to support other Unix platforms are to the MakefileProto.YourPlatform.in files. Matt Jim Rees wrote: There's also the issue of accessing in-kernel crypto if you want to use something other than des. I suspect rxk5 will probably work in the linux cache manager to begin with, and require some help to work on other platforms. ___ 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] file-locking
The short answer is, on Windows, you will find improved (see the release notes) locking semantics in OpenAFS 1.5.x. The same capability will be available for Unix-like platforms soon. http://www.openafs.org/dl/openafs/1.5.5/winnt/OpenAFSforWindows-1-5-5.exe http://www.openafs.org/release/openafs-1.5.5.html (Jeff Altman's roadmaps for the Windows client are a very helpful source of information.) Matt Richard Bronson wrote: I work for a small publishing company whose production path includes Linux, Windows and Macs. We are looking for an eventual replacement for Samba and NFS. OpenAfs is our first choice. I have setup an Afs server and several Linux, Windows-98 and Xp clients. Afs seems to do the job nicely except for one major "gotcha." We cannot get file locking to work from the Windows clients. Apparently, this has been a long-standing issue. My question is "When, if ever, will this be fixed?" Richard Bronson ___ 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] AFS and ASM (For oracle RAC) can it ? could it?
No, certainly not. On the other hand, you might look at OCFS2 on DRBD .8+ for a small RAC cluster. Matt ted leslie wrote: i am reading that NFS is worakable , but not recommended by oracle (for RAC) and certainly not a good solution. It can't do what SAN can (but SAN is $$$) I am thinking for a small DB, and given the AFS local RAM cache, could anyone comment on how sucessful Oracle RAC would be on a AFS? if it worked, boy it would be nice! -tl ___ 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-530 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: tcp or udp?
Adam Megacz wrote: My personal experience is that most places blocking UDP are also blocking TCP and forcing users to use an HTTP proxy for all internet access. Really? I'm actually interested in knowing about the prevalence of anything that falls in-between (NATted TCP but no UDP). I know it's possible, of course; are there any network devices that do this by default, or is it usually the case that networks configured this way are setup this way deliberately? Firewalls that permit only specific UDP traffic, eg, domain and ntp, would seem very common. I know it sounds like a hideous idea, but if AFS-over-TCP ever happens, I think tunnelling it inside HTTP would be a pretty useful hack. What? Given the way that most NATs work, it's actually possible to do something called "unreliable TCP". I've never seen this mentioned before, but I can't be the first person to think of it. The idea is that you "speak TCP" but always ACK all packets periodically, regardless of whether or not you got them -- the NAT can't tell the difference. So you get UDP-type performance with TCP-type compatability. With many NATs you wouldn't even need to bother with the ACKs at all. - a Google finds a lot of references to "unreliable TCP--"unreliable. TCP" and "unreliable, TCP" seem especially frequent. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info 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] Re: openafs server encryption types
Is this a statement that the enhanced encryption work, using Kerberos V, is completed in some soon-to-be-released form, Jeff? Thanks, Matt Jeffrey Altman wrote: Rahul S wrote: AFS only supports single DES enctypes at the current time. AES and RC4 will be added in the OpenAFS 2.0 release. By when is OpenAFS 2.0 expected to be out ? -Rahul S. Sometime after OpenAFS 1.4 is shipped. Jeffrey Altman -- 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] File locking
Jeff, I have been looking seriously at the Windows client with the intention of putting the stage 1 functionality there. I apologize for not coordinating with you on it previously. If you'd like to discuss this further, please drop me an email. I'd like not to interfere with getting a stable 1.4 release out. However, my understanding from Derrick is that this is a post-1.4 feature, in general. Matt Jeffrey Altman wrote: I believe Matt is working on implementing something like this for the Unix/Linux AFS clients. However, no one at the present time is working on an implementation for the Windows clients which is what you require. Normally I would be the one to do it but I will not have time to do so for several months. There are other higher priority efforts that I must work on: * helping get the OpenAFS 1.4 release out the door so there is a truly "stable" Windows release that will not suffer from unfortunate regressions due to new development * working on the rxgk security provider so there is the ability to use something other than single DES for authentication and data confidentiality * porting to 64-bit windows * adding support for the Unicode version of the CIFS/SMB protocol so that we can have large file support, dfs interoperability, Unicode path name support, etc. Byte range locking is important but it is considered to be of slightly lower priority. In any event, even if I found a few days to implement it. It would not be in the initial 1.4 release. It would be nice to get it implemented before the end of the year. Jeffrey Altman Daniel Wood wrote: -- 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] File locking
Working on it. Matt Daniel Wood wrote: Hi all, I am looking into implementing OpenAFS over a network comprised mainly of Windows clients. Having installed v1.3.84 on a Linux server, the system is working fine so far. The ability to manipulate volumes (such as moving between servers) to such an extent is particularly useful! I was wondering what the progress was as regards byte-range locking. Having searched a lot on the subject of file locking (and having had to learn a few things!), I have determined that OpenAFS utilises advisory whole-file locking but not byte-range locking. Thus Windows applications such as Microsoft Office which utilise byte-range locking are very dangerous on an AFS network due to the fact that two applications can read/write to a file. As an aside, why do Office apps use byte-range locking when they effectively lock the whole file? Having looked at archived mailing list messages referring to Stage 1/2 locking in AFS, I was curious as to the status of any work so far? Ideally (and assuming I'm vaguely right!) a mechanism whereby a file is locked on the server to prevent writes (and either reads as well or notifying the user the file is read-only as per Office) whilst enabling byte-range locks in the cache would suit our purposes, since we use shared drives where multiple users will access documents but must not be allowed to change them at the same time. This I believe is referred to as Stage 1? I get the impression that work on this would be at a tangent to the way AFS works, however that Stage 1 is feasible? Any corrections to my technical knowledge are most welcome, and any thoughts on a timescale in which this might be done if it can be done would be nice (though I do realise that's a hard thing to answer!). Without implementation of this feature I don't think we will be able to use OpenAFS which is a shame because it does it's job well! I don't think we can risk the possible loss of information it could cause, even if it is a somewhat unlikely prospect. Thanks for your time, Dan This e-mail and the information contained is confidential and is intended solely for the person to whom it is addressed. If you are not the intended recipient or have received it in error we would appreciate a prompt notice that it has been wrongly despatched and will reimburse any reasonable cost involved in notifying us. We thank you for your help in this regard. We would also advise that you should not use, disclose or copy this information in any medium, as if you do, you may be breaking the law and thereby incurring liability. We do not accept any liability to any third party acting or failing to act on, or on any information contained in this e-mail -- 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] 2005 Workshop links
Ted, I found that, for some talks, maybe ones that had slides available early, they are linked off the Agenda page for the workshop. Matt ted creedon wrote: When can we expect the 2005 Workshop presentations to be be on the openafs.org website? tedc -- 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] shadow volumes?
Jeff, Thank you for writing this--I was hoping you would jump in. Matt Jeffrey Hutzelman wrote: On Sunday, July 10, 2005 05:47:36 PM -0400 Matt Benjamin <[EMAIL PROTECTED]> wrote: These are, sort of, new in OpenAFS. Where by "sort of new" you mean "not really there at all". Your descriptions of the low-level operations are on the mark, but I wanted to provide some background on the as-yet-nonexistent high-level features that they seem to imply -- and a couple of warnings, as well... When I added the 'vos shadow' and 'vos clone' commands back in early 2004, I had in mind a mechanism by which we would keep a fileserver containing "shadow" copies of real volumes, updated on a regular basis, as a form of backups. If a fileserver were to die a horrible death, we could resurrect the volumes with loss of not more than, say, a day's worth of changes, simply by pointing the VLDB entries for those volumes at the "shadow" fileserver. The process of restoring a multi-terabyte fileserver would be reduced to minutes rather than days. I also had in mind a mechanism by which you could keep multiple online "snapshots" of a volume, which would be visible to users in some fashion so they could go back several days in time without requiring someone to do a restore. Depending on the operational model, such snapshots might be on the same server as the RW volume, or on the "shadow" fileserver. Both of these features can be built with the tools I added, but the tools alone are not sufficient. OpenAFS does not have these features, and does not even pretend to have them. Before it can, they will require additional design and implementation work: The shadow-fileserver feature requires either VLDB changes or an external database to keep track of the locations of the "shadow" volumes -- you can't just publish them in the current VLDB, because for the feature to work they have to be real RW volumes with the same ID's as the volumes from which they were copied. The multiple-snapshots feature requires VLDB changes to make it possible to associate more volume ID's with each VLDB entry, and a way to derive the names of snapshots from the names of the volumes involved. It may be more complex than that, depending on what sorts of policies you want to support for when snapshots are created and removed, and how they are named. Naming is an extremely important issue here because in order for clients to find such volumes, there need to be mount points for them somewhere in AFS, and those become somewhat tricky to manage. Of course, you could build a similar feature without changing the VLDB by using an external database and registering the clones separately in the VLDB. There are also additional problems related to the way various tools will react to additional clones and to multiple copies of the same volume on different servers. As Matt alluded to, in the namei fileserver there is a limit of 7 volumes in a volume group (an RW volume and all volumes cloned from it). In the current system, a single volume group might contain as many as four volumes - the RW itself, a backup volume, an RO or release clone if the volume is replicated, and a move clone if the volume is being moved. That essentially leaves room for 3 additional clones, or 4 if the volume in question is not replicated. I would not want to run syncvldb or syncserv against any fileserver containing these constructs. Running a syncvldb against a shadow fileserver would be disastrous -- it would update the VLDB to reflect all volumes being on the shadow server instead of the real ones. I don't know what would happen with multiple clones; I seem to remember doing some experiments in this area but don't recall the results. In short, these features do not really exist yet. The 'vos clone' and 'vos shadow' commands are not intended to provide them; they are low-level tools intended to perform specific functions which are expected to be useful in building these or similar features, and which also are sometimes useful in dealing with unusual situations. Used alone, the 'vos clone' and 'vos shadow' commands will generally _not_ leave things in a consistent state. They can be dangerous; don't use them unless you know what you're doing. Now of course, if someone wants to talk about what it would take to make these features a reality, I'd be happy to have such a conversation. But that probably belongs over on openafs-devel, rather than here. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ OpenAFS-info m
Re: [OpenAFS] shadow volumes?
Christopher, These are, sort of, new in OpenAFS. A vos copy, or a vos create followed by a vos shadow, allows you to replicate the contents of one AFS volume, to another, otherwise unrelated volume. The copy might be on a different fileserver from the original. Shadow has an incremental option, so a series of shadow operations can be done to incrementally update the copy. So essentially the topic is backup. No new type of AFS volume (eg, "shadow volume") has been created. A vos clone operation triggers cloning of a volume, giving you additional clone versions in a volume group to the traditional ones, if you want them. Without Jason's patch, these clones don't appear in VLDB. This is the part of the patch that needs most looking at--but I didn't, so, I don't say anything about it :) Jason's patch tweaks these operations somewhat to fit a backup strategy he explained partially in an earlier post. Something like, 1. Periodically shadow rw volumes to surrogates on another server, marking them readonly 2. In between shadow updates, use "vos clone" to get a COW snapshot of the surrogate, so one or a few snapshot versions are available 3. Put the clones in VLDB (but I didn't look at what the entries look like) There are issues you run into quickly with cloning. One is, limit of 4 (?) non-traditional clones of a volume stored on a namei fileserver. You can make as many volume copies as you like, at the cost of the disk to store them. I think there's a bit more to do here, but _I think_ that's the state of things at present. I was going to ask Jason for more details on his sequence of operations, but I didn't get around to it. Matt Christopher D. Clausen wrote: Someone recently posted a patch (to openafs-devel) about shadow volumes. What exactly are shadow volumes? When and why would I want to use them? I found no mention of them in the IBM documentation, on the AFSLore wiki or anything more than just the name itself mentioned in the openafs-info archives. Any additional info would be appreciated! Thanks! <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] OpenAFS and OpenSSI
This sounds like the Right Thing. :) Matt Ron Croonenberg wrote: Hi Simeon, I am actually in the process of setting something like that up. However what I am doing is set up an OpenSSI cluster that is going to run the AFS client. Ron Simeon Miteff <[EMAIL PROTECTED]> 06/28/05 7:03 AM >>> Dear All I'd like to use OpenAFS with OpenSSI. I asked on their mailing list, but no-one there seems to have tried it. Apparently the cluster-wide nfs mounting that OpenSSI does is an NFS-specific hack, and I suspect one would need to run an AFS client on each cluster node. Does anyone here have experience with this combination? Kind regards, Simeon Miteff. -- 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] FSFS Subversion repository on OpenAFS 1.3.84 problems
Blake, You should be able to host a webdav repository, from a Linux cm using the byte-range lock patch (RT), I believe. Doesn't change the situation wrt multiple clients using file-based access--only whole-file locking in that case. Matt -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 On Wed, 22 Jun 2005, Christof Hanke wrote: > Blake Atkins wrote: > > >Hello, > > > > We are running a SuSE Linux Enterprise Server 9 AFS fileserver with > > several > >Windows XP and Linux clients. Both the OpenAFS server and clients are all > >version 1.3.84 and authentication is handled by KerberosV. We have a > >Subversion repository that is being served via OpenAFS and it is problematic. > >OpenAFS on the linux workstations usually requires a restart to see some or > >all changes to the repository made by other workstations. OpenAFS on the > >Windows XP clients occasionally requires a restart due to an inability to > >access some files within the repository; access fails with an error message: > >"The system cannot find message text for message number.". > > > > Though I have not been able to locate it, I recall reading a post to > > this > >list about a similar problem with CVS + AFS. I believe the solution was a > >patch to the client source. I'm about to try downgrading the server and > >clients to 1.2.13. Is anyone else using either 1.2.X or 1.3.X OpenAFS with > >Subversion successfully? > > > >Thanks very much, > > > > > > > Hmmm, just a quote from the subversion-book: > """ > Other options can be listed with svnadmin help. As opposed to CVS, > subversion is not based on RCS, but rather on the Berkeley Database. > Make sure not to install a repository on remote file systems, like NFS, > AFS, or Windows SMB. The database requires POSIX locking mechanisms, > which these file systems do not support. > """ > > Also, see the threads about byte-range locking earlier in this list. > Boiled down, I wouldn't do that. > > -Christof > > ___ > 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] AFS cache on loop device
Sometimes people's root partition is reiserfs or xfs (or...) ... Matt Jim Rees wrote: That was easy, thanks a lot. :-) Also, there is no reason the cache has to be on a separate partition. ___ 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 cell. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Drbd with OpenAFS
If you fail over a file server on drbd, don't you have to salvage all the rw volumes immediately? Matt Pavel Semerad wrote: Has anyone has any experience with using drbd with openafs as a failover HA solution? Yes, I do. It works. -Steve Pavel Semerad ___ 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 cell. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] fine-grained incrementals?
Jeff, Marcus has suggested that the MVS backend storage is a giant memory mapped file. The data structure inside that file probably looked a lot like UFS. Matt Jeffrey Hutzelman wrote: There is no fileserver backend which stores data in a large file or directly to a block device, and there never has been. Such a thing would be possible, but it's not clear that it would be superior to the existing backends. -- 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 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 cell. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Oops in 2.6.11-rc1 ...
FYI, SuSE has backported this struct inode change to a slew 2.6 kernels, as of yesterday at 6:00 pm. Matt Kevin Coffman wrote: This does the trick. Thanks! -- 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 cell. 734-216-5309 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Linux 2.6.10-rc2 osi_misc.c structure has no member named `rlim'
1. on x86, current is an inline function which returns a pointer to the task_struct associated with the current process, it's defined in an arch-specific header (eg, include/asm-i386/current.h) 2. what Derek said IIRC, this and the EXIT_ZOMBIE are the only issues you'll run into, in making libafs, at least. Matt Derrick J Brashear wrote: On Mon, 6 Dec 2004, Helmut Jarausch wrote: Hi, here is my next problem with the Linux 2.6.10-rc2 kernel. It seems this 2.6.x kernel series is the most stable release series I can even dream of! In a statement savelim = current->rlim[RLIMIT_FSIZE].rlim_cur; /OBJ/OpenAFS/openafs-1.3.74-2.6/src/libafs/MODLOAD-2.6.10-rc2-MP/osi_misc.c:141: error: structure has no member named `rlim' 'current' seems to be a global symbol (too common a name for a global symbol) so it's even difficult to find the declaration of 'current'. it's moved into the "signal" or "signals" substructure of a task struct. i forget which. i haven't checked to be sure it's used the same, but that's the only place it is now. ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
