Messages in this thread | | | Date | Wed, 3 Feb 1999 21:32:56 +0100 | From | Matthew Wilcox <> | Subject | Re: linux capabilities and ACLs |
| |
On Wed, Feb 03, 1999 at 01:39:39PM -0600, Oliver Xymoron wrote: > I believe Ted Ts'o has a web document on the structure of ext2. A link > here would be useful.
Certainly, if anyone has it. I can't find it.
> This document digs slightly past the surface of ext2, but not deep enough > to actually help understand it.
A fair criticism. This is meant to be an introductory document to familiarise people slightly with it - somewhere between `what's a filesystem?' and reading the source code.
> For instance, you mention block groups, > but don't mention that they exist to localize disk access.
Oops, I meant to put that in.
> You mention > that there are copies of the superblock but don't mention that there's one > per block.
There isn't necessarily on later revisions of ext2..
> You talk about blocks and inodes and superblocks, but not about > the block descriptors or block and inode use bitmaps. You talk about > metadata but don't mention indirect blocks in that passage.
I'll think about these.
> A section about Linux kernel ext2 algorithms like preallocation might be > good too, since this is meant for Documentation/. Also a mention that the > filesystem has an endian spec (little-endian, IIRC) so that filesystems > should be portable.
If someone wishes to submit a diff to describe the preallocation (or any other algorithm used in ext2), feel free :-) Little-endianness added.
> A few corrections.. The limit on block size is the host operating system's > page size. I believe it's possible to have 8k blocks on some architectures > (Alpha?).
The include file says: #define EXT2_MIN_BLOCK_SIZE 1024 #define EXT2_MAX_BLOCK_SIZE 4096
I'm perfectly willing to believe one _can_ create 8k block size filesystems, nevertheless, the specification says one _may_ not.
> Directories are not inodes, they're (special) files.
Section rewritten. thanks.
> Reserved > space exists primarily to allow fragmentation avoidance. Since > fragmentation is a FAQ, this deserves mention.
I don't think it's the primary reason it exists, but I do agree this is one of its effects and I shall add this reason.
> I don't think I've ever > heard anyone talk about actually implementing fragments, so I think some > remark that they're no longer considered worthwhile should be included if > you're going to mention them. ACLs seem to be similarly out of fashion.
ACLs certainly are not out of fashion: see tsx-11's ALPHA/ext2fs directory.
-rw-rw-r-- 1 card ftp-linu 959 Apr 24 1998 e2fsprogs-1.12-WIP-acl-support.patch.gz
but I do remember fragments being considered uninteresting. I've tried to be non-judgemental about features in the document though.
> You should probably also talk a bit about creating filesystems, for > instance sparse superblocks on huge filesystems, the maximum size of > filesystems, etc.
I think that's more suitable for the mke2fs manual page.
> > Options > > ======= > > This section should come at the end, probably.
If you look at the other files in the Documentation/filesystems directory, most of them only contain this information. I think this will be the primary information that people are after when looking in this file. Therefore, I put it at the start.
> > Metadata > > -------- > > You might want to rename this section "Myths about data integrity after > crashes".
Heh. I was trying not to be inflammatory... ;-)
Thanks for your input.
-- Matthew Wilcox <willy@bofh.ai> "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." -- Donald E. Knuth, TAoCP vol 3
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |