Hi Everyone! I'm glad to announce that Alex and I agreed upon a quasi standard how to store context information in filesystem inodes ...
What is your benefit? - the binary filesystem data will be compatible so changing from one implementation to the other should work (at least regarding this information) - testing and quality assurance should be improved because we only have to verify one implementation - tools will be available to read/modify/write this on disk ctx data, hopefully also backup solutions will be possible ... Why should we do it at all? - there are some reasons for 'tagging' an inode with a 'context tag', like security issues or statistical purposes, but the major reason is a quota solution, which gives per vserver user and group quota, as well as some kind of easily configurable disk limit for each context on shared partitions ... What was agreed upon? - there are three ways to store the 16bit context information within a on disk inode structure namely UID32/GID32, UID32/GID16, and UID24/GID24 - UID32/GID32 or EXTERNAL format uses, up to now unused space within the disk inode to store the context information, this is currently only defined for ext2/ext3 but will be also defined for xfs, reiserfs, and jfs as soon as possible. you'll have full 32bit uid/gid values here ... - UID32/GID16 (works on all 32bit U/GID FSs) this format uses the upper half of the group id to store the context information. this is done transparently, so you'll never notice, except if you change the format without file conversion. it also means that you only have 16bits for gid so a maximum of 65536 groups ... - UID24/GID24 (works on all 32bit U/GID FSs) the format uses the upper quarter of user and group id to store the context information, again transparently. you'll end up with 16 million user and group ids, which should suffice for the majority of applications ... - but most important, the format you choose will have no influence on the features provided by the patches, so it's your preference ... enjoy, Herbert
