Re: linux capabilities and ACLs

Oliver Xymoron (oxymoron@waste.org)
Wed, 3 Feb 1999 13:39:39 -0600 (CST)


On Wed, 3 Feb 1999, Matthew Wilcox wrote:

> The Second Extended Filesystem
> ==============================
>
> ext2 shares many properties with traditional Unix filesystems. It has
> the concepts of blocks, inodes and directories. It has space in the
> specification for Access Control Lists (ACLs), fragments, undeletion and
> compression though these are not yet implemented (some are available as
> separate patches). There is also a versioning mechanism to allow new
> features (such as journalling) to be added in a maximally compatible
> manner.

I believe Ted Ts'o has a web document on the structure of ext2. A link
here would be useful.

This document digs slightly past the surface of ext2, but not deep enough
to actually help understand it. For instance, you mention block groups,
but don't mention that they exist to localize disk access. You mention
that there are copies of the superblock but don't mention that there's one
per block. 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.

If you're actually going to commit to describing the file system
internals, you need to reorganize things a bit. A quick outline:

- disk is addressed as blocks
- disk is split into blockgroups of (blocksize*8) blocks
- blockgroups consist of:
- superblock copy
- contains a bunch of stuff
- mention maximal mount count, etc.
- blockgroup descriptor copies
- contains number of inodes, blocks, and directories used by each group
- for balancing directory and file allocation across the disk
- local block use bitmap (one block)
- local inode use bitmap (one block)
- local inode table (inodes are 128 bytes)
- data blocks
- each file or directory is associated with one inode, which contains its
metadata, including:
- owner
- group
- permissions and node types
- time stamps
- size
- link count
- major and minor numbers for device files
- etc.
- and pointers to data blocks and indirect blocks
indirect blocks contain pointers to data or further indirect blocks
- file names are stored only in directories
- the contents of files are stored in data blocks
- system tries to store data block in the same group as inode
- mention file size limits like VFS interface, etc.
- directory data is stored in data blocks like a normal file and
is implemented as a linked list
- contains . and .. pointers
- file name length limits
- you may want to mention that they don't ever shrink
- symlinks are stored inside the inode if they're short or in a data block
if they're long

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.

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?). Directories are not inodes, they're (special) files. Reserved
space exists primarily to allow fragmentation avoidance. Since
fragmentation is a FAQ, this deserves mention. 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.

You should probably also talk a bit about creating filesystems, for
instance sparse superblocks on huge filesystems, the maximum size of
filesystems, etc.

> Options
> =======

This section should come at the end, probably.

> Metadata
> --------

You might want to rename this section "Myths about data integrity after
crashes".

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

- 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/