headers
Juri Haberland | 1 May 2008 14:27

Re: ext3 limits?

Christian Kujau wrote:
> On Tue, April 29, 2008 16:58, Eric Sandeen wrote:
>> Actually as of 2.6.18 (or is it .19...), ext3 kernel code should support
>> the full 16T, at least in terms of being able to address that many blocks
>> w/o corruption.  I did a fair amount of work in that time frame to root
>> out all the sign overflows etc to allow ext3 to get to 16T.

> Then someone should either update the FAQ or better yet put the FAQ on
> e2fsprogs.sf.net (or wherever the Ext2 homepage resides).

I'll update the FAQ as soon as possible.

Juri
Permalink | Reply | 4 comments |
headers
Christian Kujau | 1 May 2008 23:57
Picon

Re: ext3 limits?

On Thu, 1 May 2008, Juri Haberland wrote:
> I'll update the FAQ as soon as possible.

Thanks for maintaining the FAQ! Oh, and it's even referenced by the Ext3 
Wikipedia article, so it really *is* important ;-)

Christian.
--

-- 
BOFH excuse #199:

the curls in your keyboard cord are losing electricity.
Permalink | Reply | 3 comments |
headers
Theodore Tso | 2 May 2008 16:51
Picon
Picon
Favicon

Re: ext3 limits?

On Thu, May 01, 2008 at 11:57:55PM +0200, Christian Kujau wrote:
> On Thu, 1 May 2008, Juri Haberland wrote:
>> I'll update the FAQ as soon as possible.
>
> Thanks for maintaining the FAQ! Oh, and it's even referenced by the Ext3 
> Wikipedia article, so it really *is* important ;-)

Juri, would you have any objections to moving the FAQ to
ext4.wiki.kernel.org?  It might be easier to update the FAQ there.
I'll note that since it was last updated in 2004, there are a number
of questions that are mostly out of date, such as all references to
Linux 2.2, and things like ``How do I convert the journal file from
version 1 to version 2?''.

With your permission, we can mirror the questions onto
ext4.wiki.kernel.org, amd then if you would be willing to put a
redirect to new location, that would be great.

Note that the ext4.wiki.kernel.org is designed to cover ext2/3 topics
in addition to ext4 issues.

					- Ted
Permalink | Reply | 2 comments |
headers
Juri Haberland | 2 May 2008 23:31

Re: ext3 limits?

Theodore Tso wrote:
> Juri, would you have any objections to moving the FAQ to
> ext4.wiki.kernel.org? [...]

No, not at all!

> With your permission, we can mirror the questions onto
> ext4.wiki.kernel.org, amd then if you would be willing to put a
> redirect to new location, that would be great.

Sure, please do so.
Please correct me, if I'm wrong: I understand your offer also as an
offer to maintain the FAQ in the future. If you want me to maintain the
FAQ furthermore, I'll do so, but actually, I'd be glad to pass this
responsibility on ;)

When you have set up the new FAQ just give me a note and I'll set up a
301 redirect.

- Juri

PS: a tiny link back to my site would be much appreciated, but not
necessary ;)
Permalink | Reply | 1 comment |
headers
Theodore Tso | 3 May 2008 17:48
Picon
Picon
Favicon

Re: ext3 limits?

On Fri, May 02, 2008 at 11:31:51PM +0200, Juri Haberland wrote:
> Theodore Tso wrote:
> > Juri, would you have any objections to moving the FAQ to
> > ext4.wiki.kernel.org? [...]
> 
> No, not at all!
> 
> > With your permission, we can mirror the questions onto
> > ext4.wiki.kernel.org, amd then if you would be willing to put a
> > redirect to new location, that would be great.
> 
> Sure, please do so.
> Please correct me, if I'm wrong: I understand your offer also as an
> offer to maintain the FAQ in the future. If you want me to maintain the
> FAQ furthermore, I'll do so, but actually, I'd be glad to pass this
> responsibility on ;)

Well, it's in a Wiki, which means everyone can edit it.  :-)

If you would like to help out with the Wiki, more help would always be
appreciated!

						- Ted
Permalink | Reply | 0 comments |
headers
Harald_Jensas | 3 May 2008 23:16
Picon
Favicon

Best Practices for recovering corrupt ext2/3 filesystems


Hi All,

I am writing a document on Best Practices for recovering corrupt ext2/3 filesystems. The documents start
with recommending scheduling backup of partition tables and filesystem images created with e2image. I
was hopeing that the subscribers of this list might be able to verify some things for me.

Would it be safe to say that fsck would fail to recover a filesystem if the following information from
dumpe2fs on the filesystem and the filesystem image differs:

Inode count:              

Block count:              

Reserved block count:     

Block size:               
Group x: (Blocks Y-Z)

Are there any other entries that would categorize as "cannot differ" entries?

--
Harald Jensås
Permalink | Reply | 0 comments |
headers
Ross Boylan | 8 May 2008 20:25
Picon

LD_PRELOAD library to speed directory traversal

Ted Ts'o wrote spd_readdir.c
(http://marc.info/?l=mutt-dev&m=107226330912347&w=2) to improve the
performance of some applications when reading the directory.  As I
understand it, the standard system calls may not traverse in inode
order, and so can be much slower.

I am taking another crack at using this, since some backups are taking
over a day for me.

If I use it, it would be with an application that will be accessing both
ext3 and other (specifically, Reiser) filesystems.  Does anyone know if
it is safe to use in that context?

Thanks.
Ross

For reference, here's the code:
/*
 * readdir accelerator
 *
 * (C) Copyright 2003 by Theodore Ts'o.
 *
 * %Begin-Header%
 * This file may be redistributed under the terms of the GNU Public
 * License.
 * %End-Header%
 * 
 */

#define ALLOC_STEPSIZE	100
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andreas Dilger | 9 May 2008 07:49
Picon

Re: LD_PRELOAD library to speed directory traversal

On May 08, 2008  11:25 -0700, Ross Boylan wrote:
> Ted Ts'o wrote spd_readdir.c
> (http://marc.info/?l=mutt-dev&m=107226330912347&w=2) to improve the
> performance of some applications when reading the directory.  As I
> understand it, the standard system calls may not traverse in inode
> order, and so can be much slower.
> 
> I am taking another crack at using this, since some backups are taking
> over a day for me.
> 
> If I use it, it would be with an application that will be accessing both
> ext3 and other (specifically, Reiser) filesystems.  Does anyone know if
> it is safe to use in that context?

Yes, in fact for many filesystems the "inode number" does map in some
manner to disk offsets.

Please report your results here, as there isn't a lot of feedback about
using this code.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Permalink | Reply | 0 comments |
headers
Jon Vincent | 15 May 2008 18:11
Picon

Extended permissions on ext3

Hello,

I am seeing some strange behavior with extended permissions on ext3. I am writing a file as root and setting a user ACE. I then change to that user and try to access the file based on the ACL that I have set.

In the example below, I am setting a user ACE to have no permissions to access the file (---). However, I find that when I access the file as that user, I am able to read it. I find this strange because according to the man page, as soon as it matches the user ACE entry, it should allow or deny access.

If I set an identical ACL except I add the "wx" permission bits to the user ACE (-wx), I am rejected (which is what I expect). I am just wondering why I can read the file when I have no permissions (---) set on the user ACE (I expected to be rejected). Examples are below:

Example with no permissions for the user ACE:
-------------------------------------------------------------------------
[root <at> jvincent-D800 ~]# cd /tmp
[root <at> jvincent-D800 tmp]# echo "hello world" > file.txt
[root <at> jvincent-D800 tmp]# setfacl -m u::rwx,g::rwx,o::rwx,u:postgres:---,m:--- file.txt
[root <at> jvincent-D800 tmp]# getfacl file.txt
# file: file.txt
# owner: root
# group: root
user::rwx
user:postgres:---
group::rwx                      #effective:---
mask::---
other::rwx

[root <at> jvincent-D800 tmp]# ls -l file.txt
-rwx---rwx+ 1 root root 12 May  7 11:33 file.txt

[root <at> jvincent-D800 tmp]# su - postgres
[postgres <at> jvincent-D800 ~]$ id
uid=501(postgres) gid=501(postgres) groups=501(postgres)
[postgres <at> jvincent-D800 ~]$ whoami
postgres
[postgres <at> jvincent-D800 ~]$ cat /tmp/file.txt
hello world
[postgres <at> jvincent-D800 ~]$


Example with -wx permissions for the user ACE:
-------------------------------------------------------------------------
[root <at> jvincent-D800 tmp]# cd /tmp
[root <at> jvincent-D800 tmp]# echo "hello world" > file.txt
[root <at> jvincent-D800 tmp]# setfacl -m u::rwx,g::rwx,o::rwx,u:postgres:-wx,m:rwx file.txt
[root <at> jvincent-D800 tmp]# getfacl file.txt
# file: file.txt
# owner: root
# group: root
user::rwx
user:postgres:-wx
group::rwx
mask::rwx
other::rwx

[root <at> jvincent-D800 tmp]# ls -l file.txt
-rwxrwxr--+ 1 root root 12 May  7 13:47 file.txt
[root <at> jvincent-D800 tmp]# su - postgres
[postgres <at> jvincent-D800 ~]$ id
uid=501(postgres) gid=501(postgres) groups=501(postgres)
[postgres <at> jvincent-D800 ~]$ whoami
postgres
[postgres <at> jvincent-D800 ~]$ cat /tmp/file.txt
cat: /tmp/file.txt: Permission denied
[postgres <at> jvincent-D800 ~]$


Thanks!

Jon

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Permalink | Reply | 0 comments |
headers
David Woodhouse | 18 May 2008 17:39
Favicon

Re: ext3_dx_add_entry: Directory index full!

On Sun, 2008-05-18 at 17:36 +0200, Bernie Innocenti wrote:
> 
> 
>   static inline unsigned dx_root_limit (struct inode *dir, unsigned
> infosize)
>   {
>       unsigned entry_space = dir->i_sb->s_blocksize -
> EXT3_DIR_REC_LEN(1) -
>           EXT3_DIR_REC_LEN(2) - infosize;
>       return 0? 20: entry_space / sizeof(struct dx_entry);
>   }
> 
> Am I reading the above code correctly?  Why does it always return
> 20 no matter what?

It doesn't. "condition?A:B" will return A if the condition is _true_,
which it isn't.

--

-- 
dwmw2
Permalink | Reply | 1 comment |

Gmane