Hi Jeff, Jeff Mahoney wrote: > >> If I didn't search wrongly, neither quota nor ACLs are supported, yet. > >> Otherwise, it indeed looks promissing. > > There are a number of features that OCFS2 is missing, but they are being > gradually added. The OCFS2 guys (at Oracle, and some of us at SUSE) are > working on adding a lot of them. Sparse B-Trees are currently the big > holdup item, and once they're added, we get extended attributes (and > ACLs, by extension), sparse files, and hashed directories pretty soon > afterwards. Great. Then only quotas are missing, which we really need (otherwise an amok process/careless user can bring down the whole system).
> >> PS: My favourite filesystem remains AdvFS of Tru64 Unix > > Before my life as a Linux kernel hacker began, I was a system admin > running Tru64 systems. AdvFS had a lot of really interesting features, > but it was also quite fragile. I don't know how many times we ended up > needing to break out the salvage tool, which was essentially the same > thing as a reiserfsck --rebuild-tree -S, where it searches the disk > looking for *anything* that looks like it could be part of the file > system. Here, it was rather stable (as non-cluster filesystem), in the cluster it became stable/mature around the time we finally switched also the home-directory server to Linux. > We'd end up with a lot of duplicated (and potentially buggy) > code. With LVM2/dm/etc, we allow *any* file system that has the > capability to grow and/or shrink to take advantage of it. We found the possibility to have quotas on filesets rather nice: Each group (at the department) got its own fileset with a large quota. Thus we could grant a rather big chunk to each group with a big quota, including overcommitting the available space. Thus we didn't need to estimate too carefully, how much memory each group needed, still the quota prevented the filling of all space (amok process) and as most groups never used their available space, the overcommitting was no problem. (We had no user-specific quota for the groups, only for the students.) > File sets and file domains were an interesting concept, but I don't > think it would be too difficult to extend existing file systems to > behave similarly. The file system-global superblock could remain mostly > the same with the root directory containing entries on where to find the > sub-file system's superblock. The thing is, I just don't think it's a > feature a lot of people are looking for. See above. Similar interesting concept is the project quota of XFS (see man xfs_quota): "XFS supports the notion of project quota, which can be used to implement a form of directory tree quota (i.e. to restrict a directory tree to only being able to use up a component of the filesystems available space; or simply to keep track of the amount of space used, or number of inodes, within the tree)." At least for our use, outlined above, these two are equivalent. The only difference is that using xfs_quota, the checking of the quota is more difficult; with filesets, one can simply use "df -h ." In how far does OCFS2 support shrinking (and growing) of the filesystem? Tobias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
