linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Burschik <Michael.Burschik@gmx.de>
To: linux-ext4@vger.kernel.org
Cc: Theodore Ts'o <tytso@mit.edu>
Subject: Re: Design alternatives for fragments/file tail support in ext4
Date: Fri, 13 Oct 2006 08:19:16 +0200	[thread overview]
Message-ID: <452F2FE4.4010401@gmx.de> (raw)
In-Reply-To: <E1GXeYv-0006rP-RV@candygram.thunk.org>

Theodore Ts'o wrote:
> Storing the tail as an extended attribute
> =========================================
>
> Stephen and I have discussed this in the past, and the idea is a simple
> one; simply store the tail as an extended attribute.  There are other
> filesystems that have done this, most notably NTFS (post-Windows 2000).
> However, this approach is a little unsatisfying to me, since it buys us
> nothing if there are no other extended attributes contained by the
> filesystem, and if we are using large inodes to accelerate extended
> attributes, there won't be much space for any but the smallest tails
> (i.e., if we are using 4k blocks, and 512 byte inodes, the largest tail
> that we could store using this method is around 350 bytes or so.)
>
> Using this technique would only require a flag in the inode indicating
> it has a fragment, so the filesystem knows to look for the extended
> attribute.  In theory this could also be done by checking the i_size
> field, and assuming that last block in the file can never normally be a
> hole, but this can be quite fragile.
>
>   
Disclaimer: I am not a file system expert.

That said, I still think there are some advantages to this scheme. First 
of all, 350 bytes are not all that bad. Many short files are 
configuration files, and many of them are shorter than 350 bytes 
(resolv.conf, hostname, hosts, etc.). On my system I find more than 300 
files shorter than 512 bytes in /etc, and more than 700 in my home 
directory. Some applications read many configuration files, so I would 
expect this scheme to lead to a considerable speed improvement. 
Moreover, there is much to be said in favour of configuration systems 
that store exactly one value per file, such as tcb and Elektra.

Secondly, I expect systems that do not use extended attributes to become 
increasingly rare. SELinux has become mainstream. It is included in Red 
Hat/Fedora, Ubuntu, Debian etch (IIRC). Desktop software such as Beagle 
uses extended attributes if available, and I expect this tendency to 
increase. Desktop software is also notorious for needing vast numbers of 
configuration files.

Regards

Michael Burschik

  reply	other threads:[~2006-10-13  6:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-11 13:55 Design alternatives for fragments/file tail support in ext4 Theodore Ts'o
2006-10-13  6:19 ` Michael Burschik [this message]
2006-10-13  8:10 ` Andreas Dilger
2006-10-13 10:49   ` Theodore Tso
2006-10-13 10:56     ` Alex Tomas
2006-10-13 12:23       ` Theodore Tso
2006-10-13 17:47         ` Andreas Dilger
2006-10-13 12:48 ` Erik Mouw
2006-12-02 11:02 ` Alex Tomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=452F2FE4.4010401@gmx.de \
    --to=michael.burschik@gmx.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).