FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 03-14-2013, 07:57 PM
 
Default ext4 and extremely slow filesystem traversal

>>>> It also has 0 reserved blocks.

>> That's usually a truly terrible setting (20% is a much better
>> value), but your filesystem is not very full anyhow.

> This filesystem has no file owned by root and won't have
> any. I thought in this case -m0 would be a good idea.

Why does it matter here that "no file owned by root"?

What has that got to do with the much greater difficulty to find
contiguous space the fuller the filetree is?

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-14-2013, 09:56 PM
Vincent Caron
 
Default ext4 and extremely slow filesystem traversal

On 14/03/2013 21:57, Peter Grandi wrote:
>> This filesystem has no file owned by root and won't have
>> > any. I thought in this case -m0 would be a good idea.
> Why does it matter here that "no file owned by root"?
>
> What has that got to do with the much greater difficulty to find
> contiguous space the fuller the filetree is?

Because the man page says that reserved blocks are used to protect
root-level daemons from misbehaving would unprivileged programs try to
fill the disk. And uh, to avoid fragmentation, I missed that part.

OTOH I monitor disk space and never let go past 95% block usage
without specific action (freeing inodes or enlarging filesystem). Would
I use -m5 and oversize my filesystems (because I sell the capacity, say
I sell 100GB then I need a 105GB blockdev), I would still monitor the
disk usage and take action before it's 100% filled up. But I'd end up
reserving more blocks without more guarantees that the -m0 case.

So technically it looks wrong, but politically I'm not sure it's
stupid. Or is it ?

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-14-2013, 10:07 PM
Vincent Caron
 
Default ext4 and extremely slow filesystem traversal

On 14/03/2013 02:05, Theodore Ts'o wrote:
> Just as a note, e2fsck -v can sometimes get this information much more
> quickly than other alternatives, since it can scan the file system in
> inode order, instead of the essentially random order.
>
> Just as a side, if you just want to get a rough count of the number of
> directories, you can get that by grabbing the information out of
> dumpe2fs.

Very useful. Global stats without having to scan the whole filesystems
are very precious...

I was wondering : couldn't we use dumpe2fs or something based on
libext2fs to quickly extract a snapshot of all inodes from a given
filesystem ? For incremental backups, simply checking the mtime on
millions of inodes and discovering that only a handful of them were
updated since the previous pass looks very inefficient with
readdir()+lstat(). So mnay syscalls, so man spoonfed bits of
information. When I had a peek, I tought I'd got a list of inodes but
would not be able to link them back to their name(s) without inducing
the same cost as a regular find-like filesystem traversal. Does it make
sense ?

AFAIK I would be better served with block-level snapshot solutions,
but LVM snapshots are supposed to double your writes if I got it right,
and I'm not sure there's something else in the Linux and free software
world. Plus I'd love to not migrate away from my ext3/4's without a
compelling reason. Btrfs is not (yet) and option and ZFS doesn't fit
legally with Linux.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-15-2013, 06:14 AM
Andreas Dilger
 
Default ext4 and extremely slow filesystem traversal

On 2013-03-14, at 16:07, Vincent Caron <vcaron@bearstech.com> wrote:

> On 14/03/2013 02:05, Theodore Ts'o wrote:
>> Just as a note, e2fsck -v can sometimes get this information much more
>> quickly than other alternatives, since it can scan the file system in
>> inode order, instead of the essentially random order.
>>
>> Just as a side, if you just want to get a rough count of the number of
>> directories, you can get that by grabbing the information out of
>> dumpe2fs.
>
> Very useful. Global stats without having to scan the whole filesystems
> are very precious...
>
> I was wondering : couldn't we use dumpe2fs or something based on
> libext2fs to quickly extract a snapshot of all inodes from a given
> filesystem ? For incremental backups, simply checking the mtime on
> millions of inodes and discovering that only a handful of them were
> updated since the previous pass looks very inefficient with
> readdir()+lstat().

That's exactly what e2scan does. I'm pretty sure that is in upstream e2fsprogs now (not just our Lustre version), but I'm on a plane and cannot check.

It will scan the inode table directly and can generate the pathnames of files efficiently. It can filter on timestamps.

Cheers, Andreas

> So mnay syscalls, so man spoonfed bits of
> information. When I had a peek, I tought I'd got a list of inodes but
> would not be able to link them back to their name(s) without inducing
> the same cost as a regular find-like filesystem traversal. Does it make
> sense ?
>
> AFAIK I would be better served with block-level snapshot solutions,
> but LVM snapshots are supposed to double your writes if I got it right,
> and I'm not sure there's something else in the Linux and free software
> world. Plus I'd love to not migrate away from my ext3/4's without a
> compelling reason. Btrfs is not (yet) and option and ZFS doesn't fit
> legally with Linux.
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-16-2013, 10:17 AM
Bodo Thiesen
 
Default ext4 and extremely slow filesystem traversal

* Vincent Caron <vcaron@bearstech.com> hat geschrieben:

> AFAIK I would be better served with block-level snapshot solutions,
> but LVM snapshots are supposed to double your writes if I got it right,
> and I'm not sure there's something else in the Linux and free software
> world.

There is a simple and reliable solution for block level backups: dd

umount && dd if="our raid partition" of="some new big enough disc" &&
mount

and then wait for the data to go at 100MB/s or so to the new disc.

Using snapshots is not a reliable way to do backups, since you would
still have to trust the LVM code to be totally error free and protect
your data under any circumstances (including hardware failures in your
raid array etc).

For your actual problem: Ask your developers to use some mapping
system.

When they want to access a file "filename" then calculate md5sum of
"filename", take the first 6 characters of the ascii representation
(here it would be 435ed7) and create a file called "43/5e/d7-X".
This way you would end up with at most 65792 directories. The X is needed
to distinquish between files with same 6 first letters md5sum. So, first
file gets name "43/5e/d7-1", second file gets name "43/5e/d7-2" and so on.

Somewhere else, they would then store the mapping table, mapping file
"filename" to "43/5e/d7-2". All accesses go through this mapping table.

Regards, Bodo

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-16-2013, 10:29 AM
Bodo Thiesen
 
Default ext4 and extremely slow filesystem traversal

* Vincent Caron <vcaron@bearstech.com> hat geschrieben:

> On 14/03/2013 21:57, Peter Grandi wrote:
> >> This filesystem has no file owned by root and won't have
> >> > any. I thought in this case -m0 would be a good idea.
> > Why does it matter here that "no file owned by root"?
> >
> > What has that got to do with the much greater difficulty to find
> > contiguous space the fuller the filetree is?
>
> Because the man page says that reserved blocks are used to protect
> root-level daemons from misbehaving would unprivileged programs try to
> fill the disk. And uh, to avoid fragmentation, I missed that part.
>
> OTOH I monitor disk space and never let go past 95% block usage
> without specific action (freeing inodes or enlarging filesystem). Would
> I use -m5 and oversize my filesystems (because I sell the capacity, say
> I sell 100GB then I need a 105GB blockdev), I would still monitor the
> disk usage and take action before it's 100% filled up. But I'd end up
> reserving more blocks without more guarantees that the -m0 case.
>
> So technically it looks wrong, but politically I'm not sure it's
> stupid. Or is it ?

Using -m technically makes the file system driver report ENOSPC when
there is in fact still free space available.

So, as long as you make sure, that you have at least 5% free space at any
given time, it doesn't matter whether you have -m0 or -m5. However, tools
like df show the available capacity to user space, so 100GB with 95GB used
will show 100% used with -m5 and 95% used with -m0. Effectively, that
means, when you go with -m5 and make sure, df shows at least 5% free space,
you end up with about 10% free all the time - this way reducing
fragmentation - in theory. Since you're missusing your file system as
data bank management system with many small files anyways,
inter file fragmentation is the least of your problems. So, it's totally
safe for you to stay with -m0.

Regards, Bodo

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-24-2013, 09:40 PM
Vincent Caron
 
Default ext4 and extremely slow filesystem traversal

On 15/03/2013 08:14, Andreas Dilger wrote:
> That's exactly what e2scan does. I'm pretty sure that is in upstream e2fsprogs now (not just our Lustre version), but I'm on a plane and cannot check.
>
> It will scan the inode table directly and can generate the pathnames of files efficiently. It can filter on timestamps.

I did not find it in git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

There are some references from Lustre doc [1] and I could find some
github repo with some code [2]. Would you know where the e2scan upstream
lives ?


[1]
http://wiki.lustre.org/manual/LustreManual20_HTML/SystemConfigurationUtilities_HTML.html#50438219_55 923
[2] https://github.com/morrone/e2fsprogs

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 

Thread Tools




All times are GMT. The time now is 07:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org