Jeff Garzik wrote: > J. Bruce Fields wrote: >> >> http://www.connectathon.org/ >> >> > As this isn't an official RH project, I would probably have to pay my > own way, which makes it doubtful :) >
It's entirely possible someone might run your server code on a spare machine, given functioning install packages and easy instructions. > Plus, surely in this day and age, we can figure out something better > than waiting for face-to-face events to test something. Maybe somebody > could arrange a donation of some slice of a grid (Amazon EC2?), make > various OS images available, and give engineers some way to request a > selection of tests, with a selection of OS images? > Vendors turn up to cthon with proprietary and unreleased software and hardware which they most certainly are not going to let anyone else run for them. Also, being in the same hall with all those vendors' technical folks tends to make bugs shallow. It's a very valuable exercise for any organisation making a living from NFS. > I really wish the entire wire protocol were scrapped and replaced with > something more sane, and easier to parse. You had me worried there for a moment, I thought you might be the first person to admit to liking the NFS4 protocol design. > It's tempting to see what would arise from a clean-slate wire protocol > effort, something that is otherwise compatible with NFS 4.x operations, > objects, and data model. > Much like the old phone system, the primary value of protocols like NFS is the widespread presence of reliable conformant implementations. Most of the rest of the NFS is problematic. I would argue that some aspects of the NFS operations, objects, and data model is rather more busted than the XDR encoding. The classic persistent file handles, for example, could be considered a major design flaw. Firstly it makes the inode# -> dentry lookup a performance path for the underlying filesystem, which it isn't in any local load. Secondly, it's inherently insecure if you export anything less than an entire filesystem, unless you use a slow, buggy, and non-conformant hack like subtree_check. Another major flaw is putting the client in control of when unstable data is written to disk, but not providing any way for the client to find out how to do that optimally. Then there's the NFS4 approach to extended attributes. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
