Re: Default ext inode size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 13, 2008 at 03:50:08PM -0500, Phillip Susi wrote:
> Theodore Tso wrote:
>> That's the main one.  The other benefit is that ext4 uses a bigger
>> inode to store some extra fields such as the file creation time,
>> nanosecond timestamps, and the 64-bit version number neede which is
>> used for NFSv4's client-side caching.
>
> What about ext3?  Does it do the same thing with the larger inode?  Does  
> it get more block pointers or room for block extent lists ( in ext4 )?  
> Are the higher resolution timestamps used by default if the inode is  
> large, or is there a compatibility bit and/or mount option that needs 
> set?

No, ext3 doesn't have any of these features; only ext4.  It would be
possible to backport things like the high res timestamps to ext3, but
no one has done it to date.

We don't actually use extra block extent lists in ext4 with the extra
space.  We could, but it's not clear how much it is necessary.  On my
laptop, which has been running ext4 since July, a recent check on my
system showed that I had 1,058,309 inodes used, and of those roughly
one million inodes used, 548 inodes had a extent depth of one, and
exactly 2 inodes had an extent depth of two.  All of the other inodes
had 3 or fewer extents, so they all fit inside the current inode's
direct block array.  In fact, all but 10,876 inodes were contiguous
(i.e., only needed one extent).

Granted, my laptop is used as a development machine, which means the
bulk of the files are Maildir directories, git repositories, and build
trees, which might not be representative of say, server workloads.
Still, statistics of 98.97% of the files being completely contiguous,
and 99.95% of the files being able to store all of their extents
inside the inode table and not needing to spill to an external extent
tree are pretty impressive, and a good reason for folks to migrate to
ext4 when they have a chance.  :-)

> Does it actually help performance to store the ae in the inode?  I would  
> think it would not make much difference if many files have the same  
> attributes, then the shared ea block would be cached.

I don't use SE Linux, so I can't speak to this from personal
experience.  People who have enabled it have told me the performance
difference is "dramatic".

It also seemed that with the advent of desktop programs like Beagle,
there were more desktop applications using file-unique extended
attributes, and that my personal battle to tell application programs
that "friends don't let friends use extended attributes" was a losing
fight, and given that the GNOME and KDE application programs have
filesystems engineers vastly outnumbered, it was better to assume that
we weren't going to win this one, as they pick up bad programming
habits from platforms such as Mac OS X.  :-)

> Probably, but it is an example ( and there probably are others ) of  
> problems caused by changing the default, so I'm trying to understand why  
> ext3 was disturbed in this way rather than just make 256 byte inodes the  
> default for only ext4.

We didn't "disturb" ext3; we just changed the default, to reflect the
changing usage of filesystems.  If a system administrator is convinced
that thye know better, they can always adjust /etc/mke2fs.conf, and
change the default to something else.

I know of only one other problem that was turned up when we changed
the default, which was that some boot loaders didn't know how to deal
with 256 byte inodes.  But that got fixed pretty fast.

Realistically, any userspace program that uses libext2fs would have
been fine, since it always did the right thing with larger inode
sizes.  It was only a programs that didn't use the standard ext2
library that would get bitten, and there are very few of those around.

	     	       	       	   	     	  - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux