On Fri, Jul 9, 2010 at 10:05, David P. Quigley <dpquigl@xxxxxxxxxxxxx> wrote: > On Fri, 2010-07-09 at 08:48 +1000, James Morris wrote: >> Yes, but we should not unnecessarily limit the network protocol when >> something is valid and possible in the local implementation (which is ~64k >> under Linux). >> >> A security label include just about anything, e.g. an x509 certificate, or >> a base64 encoded image. >> >> In the Linux implementation, if we can store a local label up to 64k, then >> we should try and ensure that it can be conveyed via NFS. > > If you want that to be the case you need to make your case to Trond > about that. I've already had this conversation before and he seems to > think that a page is sufficient. Bruce also has concerns about not > wanting these labels to require a high order allocation. Under memory > pressure finding 16 contiguous pages for each label might be a problem. I would argue that if somebody wants to stick a base64-encoded image or an x509 certificate in their security labels then shipping the whole thing across the wire every time somebody does an extended "stat" is just stupid. Think about how much overhead there would be if you did an "ls -Z" of a directory with 100 files (64k * 100 == 6.4MB!!!), where that data would previously have fit in no more than 10-20k TOTAL. A better solution would be something along the lines of putting at most a SHA512 sum in the label field and have a separate caching communication protocol (either in-band or out-of-band) to pass the fully-descriptive payload. Even in local filesystems like ext3 we prefer to turn labels into numbers, store the number with each inode, and then keep the labels indexed in a separate datastructure. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
