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/