[KLUG Members] quota

[Adam Tauno Williams]

> > Already here - XFS.  XFS performs dynamic space allocation and for very
> > small files just stores the contents as meta-data inside the files inode
> > entry in the space that would be used by the block-map of a 'large'
> > file.  Inode allocation is also handled dynamically, rather than
> > creating a static number when the filesystem is created (like ext2,
> > ext3, etc...).  The inode count can both increase and decrease
> > on-demand.
> Adam ,Can you put that in plain english ? Please

UNIX filesystem symantics: a filesystem (traditionally) is in two parts:
inodes and data blocks 

(XFS is actually 3 + n parts: inodes, meta-data, (data * AG), but thats
another story).

A file (be it a special file, regular file, sparse file, whatever...) is
an inode.   An inode is like an entry in the filesystems table of
contents.  The inode contains things like size, etc... (BUT NOT THE
NAME!).

A directory is a type of special file that relates names to inodes; that
is how a file can exist in multiple directories and/or have multiple
names (the reference count seen in ls output)  A directory itself has an
inode - it is a file.

So every entity that exists in a  filesystem consumes 1 inode.

The data area of a filesystem is carved into X number of blocks all of Y
size.  The filesystem also contains a list (in some form or another) of
all the blocks that are not allocated,  sometimes called the 'free
list'.

The inode contains a block-map, a list of all the blocks (in order) that
are allocated to the entity it represents.  When a file's size is
reduces blocks are dereferences in the inode block map, when a file's
size is increased additional blocks (from the available empty blocks)
are added to the block map.

Hence (traditionally) a file cannot be smaller that 1 block (usually
~4k).  It just means only part of that block is used.

Since quotas are meant to control disk consumption they use block count,
not size - and this is a good thing,  because block count is what really
matters.  1000 1k files consume 16,000k (fileCount * BlockSize) of
actual disk space.

As you can see, this is dumb.

The inode block map for every file on an XFS filesystem is about ~2k. 
So if the file is less than 2k XFS uses the inode block map area itself
to store the contents of the file, and performs no data block
allocation.

(a) This leaves the data block available for use by other larger files.
(b) Since opening a file ***ALWAYS*** involves reading its inode -
opening a small file can be accomplished in 2 I/O operations (seekInode
+ readInode) vs 4 (seekInode + readInode + seekDataBlock +
readDataBlock)
(c) A typical filesystem contains MANY <2k files.
(d) Allocating a datablock requires LOCKING the free list, so only a
limited number of file-size-expansions can occur at once (on a
traditional filesystem ONLY *ONE* can occur at a time, XFS works around
that, but the number is still at something like 4 - 16).  By using the
inode to store data the free list never has to be locked for allocation
unless the filesize increases past 2k.