Christopher D. Clausen wrote: > Perhaps some of these millions of dollars from these research projects > can go into testing to provide a "better" AFS client that is both fast > AND reliable.
Rodney doesn't control the money. It would be wonderful if the cost of AFS was paid for as part of the overhead tax on research grants but this is not Rodney's decision. > Are you currently paying to cover any of the development costs for AFS? > Do you have a support contract with any company specifically for AFS > support? Give Rodney a break. Not only has Rodney supported the development of OpenAFS since I lambasted on this mailing list in early 2004 but he also has one of the most complex deployments of OpenAFS for Windows that I am aware of. He has more than 200 applications running out of AFS plus all of the user's profiles. He has been extremely ambitious in using OpenAFS to its fullest potential and unfortunately OpenAFS has sometimes let him down. Rodney has also been extremely good about filing excellent reports and helping to reproduce scenarios so that bugs can be fixed ASAP. > I find that now is an appropriate time to post this link: > http://people.ccmr.cornell.edu/~mitch/afsvsnfs.html To which I will reply with: http://www.coe.uncc.edu/~rmdyer/ > But seriously, if AFS is at the point where non-professional geeks look > at it and say "AFS rules!" then something has been done right. Right > now people just look at it and say "its not that bad" and then go on and > look at other "cool" alternatives. Anyone want to help us get AFS running on the Nokia N8xx Internet Tablet or a Symbian based phone? > Many would-be AFS admins stop by and ask questions in the #openafs IRC > channel. Most of them go something like this: > * newuser1 has joined the channel > newuser1: Hi! I heard that AFS can do replication. > afsadmin1: yes, but only for read-only data > afsadmin2: if you want real-time replication, you probably need to look > at something else. > newuser1: oh? really? Too bad. > * newuser1 has left the channel Yeah I know the story well. Derrick and I have some serious ideas about how we can provide a read-write volume type that supports replication for reads but requires that all writes and lock requests go to a single server. > The other conversations involve those already using AFS and post > high-school geeks who DO want to setup something cool. The AFS > community isn't going to grow if these people are insulted and > discouraged from testing various new and cool technologies. At the same time we need to respect the frustrated overworked IT professionals who have risked then reputations in order to help get OpenAFS to where it is today. > I know this is isn't a useful data point, but to my knowledge, none of > the AFS servers that I maintain have lost important data due to a fault > in AFS. Yes, some test data was lost, but that is exactly why a > "professional" sysadmin runs tests in the first place. Have you > actually lost data? The data loss bug in the OpenAFS for Windows and IBM AFS for Windows clients that were fixed in OpenAFS 1.5.15 were very real. This is not hypothetical data loss. Nor is data lost on the client because Word decided to crash when a network write failure occurred. Not because the AFS client lost communication with the file server but because the Microsoft CIFS client decided that AFS was taking too long. > Or are you just concerned about truthful warnings > posted by the developers? (Of course I realize that there is always the > possibility that data is corrupted and one doesn't know yet. Volunteer > and help test new builds to help reduce these possibilities or fund > development.) Rodney does. > I will also point out that a salesperson for a commercial company isn't > as likely to tell you that his/her company's product will not work in > your situation. The AFS community IS more likely to tell you the > reality of the situation. AFS is not better than filesystem y, at least > not yet. Ok. Now that we are all friends again can we get back to the business of making OpenAFS a better product? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
