headers
Renato S. Yamane | 1 Mar 2010 02:04
Picon

[Linux 2.6.32.9] fsck.ext4: Unable to resolve UUID...

[Let me in cc because I'm not subscribed on this ML]

Hi,
When I try use linux 2.6.32.9 I get a boot error:

fsck.ext4: Unable to resolve UUID=c48fd15a-8e30-473c-b7c2-6b8a1d02fb46
fsck died with exit status 8

Check here:
<http://img188.imageshack.us/img188/1548/booterror.jpg>

When I use linux 2.6.32.7 this kind of problem don't happening (on the 
same laptop).

Regards,
Renato S. Yamane
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andreas Dilger | 1 Mar 2010 09:39
Picon

Re: EXT4 is ~2X as slow as XFS (593MB/s vs 304MB/s) for writes?

On 2010-02-28, at 07:55, Justin Piszcz wrote:
> === CREATE RAID-0 WITH 11 DISKS

Have you tried testing with "nice" numbers of disks in your RAID set  
(e.g. 8 disks for RAID-0, 9 for RAID-5, 10 for RAID-6)?  The mballoc  
code is really much better tuned for power-of-two sized allocations.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Karsten Weiss | 1 Mar 2010 09:57
Picon

Re: Bad ext4 sync performance on 16 TB GPT partition

Hi Eric,

On Fri, 26 Feb 2010, Eric Sandeen wrote:

> > => The problem shows only with the CentOS / Red Hat 5.4 kernels (including 
> > RH's test kernel 2.6.18-190.el5). Aadmittedly ext4 is only a technology 
> > preview in 5.4...
> > 
> > I've also tried the latest CentOS 5.3 kernel-2.6.18-128.7.1.el5 but 
> > couldn't mount the device (with -t ext4dev).
> > 
> > 2.6.18-164.el5 (the initial CentOS 5.4 kernel) has the bug, too.
> > 
> > I'm willing to test patches if somebody wants to debug the problem.
> 
> Ok, that's interesting.  We've not had bona-fide RHEL customers report
> the problem, but then maybe it hasn't been tested this way.

I think so because, as I mentioned, the issue can be reproduced with the 
RH test kernel 2.6.18-190.el5 x86_64 (http://people.redhat.com/jwilson/el5/),
too.

> 2.6.18-178.el5 and beyond is based on the 2.6.32 codebase for ext4.
> 
> Testing generic 2.6.32 might also be interesting as a datapoint,
> if you're willing.

Sorry for the delay, here's the (good) 2.6.32 result:

# /usr/bin/time bash -c "dd if=/dev/zero of=/mnt/large/10GB bs=1M count=10000 && sync"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Justin Piszcz | 1 Mar 2010 10:21

Re: EXT4 is ~2X as slow as XFS (593MB/s vs 304MB/s) for writes?


On Mon, 1 Mar 2010, Andreas Dilger wrote:

> On 2010-02-28, at 07:55, Justin Piszcz wrote:
>> === CREATE RAID-0 WITH 11 DISKS
>
>
> Have you tried testing with "nice" numbers of disks in your RAID set (e.g. 8 
> disks for RAID-0, 9 for RAID-5, 10 for RAID-6)?  The mballoc code is really 
> much better tuned for power-of-two sized allocations.

Hi,

Yes, the second system (RAID-5) has 8 disks and it shows the same 
performance problems with ext4 and not XFS (as shown from previous 
e-mail), where XFS usually got 500-600MiB/s for writes.

http://groups.google.com/group/linux.kernel/browse_thread/thread/e7b189bcaa2c1cb4/ad6c2a54b678cf5f?show_docid=ad6c2a54b678cf5f&pli=1

For the RAID-5 (from earlier testing):  <- This one has 8 disks.
-o data=writeback,nobarrier: 
10737418240 bytes (11 GB) copied, 48.7335 s, 220 MB/s 
-o data=writeback,nobarrier,nodelalloc: 
10737418240 bytes (11 GB) copied, 30.5425 s, 352 MB/s 
An increase of 132MiB/s.

Justin.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michal Schmidt | 1 Mar 2010 13:34
Picon
Favicon

[PATCH] ext4: reduce scheduling latency with delayed allocation

mpage_da_submit_io() may process tens of thousands of pages at a time.
Unless full preemption is enabled, it causes scheduling latencies in the order
of tens of milliseconds.

It can be reproduced simply by writing a big file on ext4 repeatedly with
dd if=/dev/zero of=/tmp/dummy bs=10M count=50

The patch fixes it by allowing to reschedule in the loop.

cyclictest can be used to measure the latency. I tested with:
$ cyclictest -t1 -p 80 -n -i 5000 -m -l 20000

The results from an UP AMD Turion 2GHz with voluntary preemption:

Without the patch:
T: 0 ( 2535) P:80 I:5000 C:  20000 Min:   12 Act:  23 Avg: 3166 Max:  70524
(i.e. Average latency was more than 3 ms. Max observed latency was 71 ms.)

With the patch:
T: 0 ( 2588) P:80 I:5000 C:  20000 Min:   13 Act:  33 Avg:   49 Max:  11009
(i.e. Average latency was only 49 us. Max observed latency was 11 ms.)

Signed-off-by: Michal Schmidt <mschmidt <at> redhat.com>
---
 fs/ext4/inode.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e119524..687a993 100644
--- a/fs/ext4/inode.c
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Tokarev | 1 Mar 2010 15:48
Picon

Re: EXT4 is ~2X as slow as XFS (593MB/s vs 304MB/s) for writes?

Justin Piszcz wrote:
> 
> On Mon, 1 Mar 2010, Andreas Dilger wrote:
> 
>> On 2010-02-28, at 07:55, Justin Piszcz wrote:
>>> === CREATE RAID-0 WITH 11 DISKS
>>
>> Have you tried testing with "nice" numbers of disks in your RAID set
>> (e.g. 8 disks for RAID-0, 9 for RAID-5, 10 for RAID-6)?  The mballoc
>> code is really much better tuned for power-of-two sized allocations.
> 
> Hi,
> 
> Yes, the second system (RAID-5) has 8 disks and it shows the same
> performance problems with ext4 and not XFS (as shown from previous
> e-mail), where XFS usually got 500-600MiB/s for writes.
> 
> http://groups.google.com/group/linux.kernel/browse_thread/thread/e7b189bcaa2c1cb4/ad6c2a54b678cf5f?show_docid=ad6c2a54b678cf5f&pli=1
> 
> 
> For the RAID-5 (from earlier testing):  <- This one has 8 disks.

Note that for RAID-5, the "nice" number of disks is 9 as Andreas
said, not 8 as in your example.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Justin Piszcz | 1 Mar 2010 16:07

Re: EXT4 is ~2X as slow as XFS (593MB/s vs 304MB/s) for writes?


On Mon, 1 Mar 2010, Michael Tokarev wrote:

> Justin Piszcz wrote:
>>
>> On Mon, 1 Mar 2010, Andreas Dilger wrote:
>>
>>> On 2010-02-28, at 07:55, Justin Piszcz wrote:
>>>> === CREATE RAID-0 WITH 11 DISKS
>>>
>>> Have you tried testing with "nice" numbers of disks in your RAID set
>>> (e.g. 8 disks for RAID-0, 9 for RAID-5, 10 for RAID-6)?  The mballoc
>>> code is really much better tuned for power-of-two sized allocations.
>>
>> Hi,
>>
>> Yes, the second system (RAID-5) has 8 disks and it shows the same
>> performance problems with ext4 and not XFS (as shown from previous
>> e-mail), where XFS usually got 500-600MiB/s for writes.
>>
>> http://groups.google.com/group/linux.kernel/browse_thread/thread/e7b189bcaa2c1cb4/ad6c2a54b678cf5f?show_docid=ad6c2a54b678cf5f&pli=1
>>
>>
>> For the RAID-5 (from earlier testing):  <- This one has 8 disks.
>
> Note that for RAID-5, the "nice" number of disks is 9 as Andreas
> said, not 8 as in your example.
>
> /mjt
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Sandeen | 1 Mar 2010 17:15
Picon
Favicon
Gravatar

Re: EXT4 is ~2X as slow as XFS (593MB/s vs 304MB/s) for writes?

Justin Piszcz wrote:
> 
> 
> On Sun, 28 Feb 2010, tytso <at> mit.edu wrote:
> 
>> On Sat, Feb 27, 2010 at 06:36:37AM -0500, Justin Piszcz wrote:
>>>
>>> I still would like to know however, why 350MiB/s seems to be the maximum
>>> performance I can get from two different md raids (that easily do
>>> 600MiB/s
>>> with XFS).
> 
>> Can you run "filefrag -v <filename>" on the large file you created
>> using dd?  Part of the problem may be the block allocator simply not
>> being well optimized super large writes.  To be honest, that's not
>> something we've tried (at all) to optimize, mainly because for most
>> users of ext4 they're more interested in much more reasonable sized
>> files, and we only have so many hours in a day to hack on ext4.  :-)
>> XFS in contrast has in the past had plenty of paying customers
>> interested in writing really large scientific data sets, so this is
>> something Irix *has* spent time optimizing.
> Yes, this is shown at the bottom of the e-mail both with -o data=ordered
> and data=writeback.

...

> === SHOW FILEFRAG OUTPUT (NOBARRIER,ORDERED)
> 
> p63:/r1# filefrag -v /r1/bigfile Filesystem type is: ef53
> File size of /r1/bigfile is 10737418240 (2621440 blocks, blocksize 4096)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Sandeen | 1 Mar 2010 17:22
Picon
Favicon
Gravatar

Re: Bad ext4 sync performance on 16 TB GPT partition

Karsten Weiss wrote:
> Hi Eric,
> 
> On Fri, 26 Feb 2010, Eric Sandeen wrote:
> 
>>> => The problem shows only with the CentOS / Red Hat 5.4 kernels (including 
>>> RH's test kernel 2.6.18-190.el5). Aadmittedly ext4 is only a technology 
>>> preview in 5.4...
>>>
>>> I've also tried the latest CentOS 5.3 kernel-2.6.18-128.7.1.el5 but 
>>> couldn't mount the device (with -t ext4dev).
>>>
>>> 2.6.18-164.el5 (the initial CentOS 5.4 kernel) has the bug, too.
>>>
>>> I'm willing to test patches if somebody wants to debug the problem.
>> Ok, that's interesting.  We've not had bona-fide RHEL customers report
>> the problem, but then maybe it hasn't been tested this way.
> 
> I think so because, as I mentioned, the issue can be reproduced with the 
> RH test kernel 2.6.18-190.el5 x86_64 (http://people.redhat.com/jwilson/el5/),
> too.
> 
>> 2.6.18-178.el5 and beyond is based on the 2.6.32 codebase for ext4.
>>
>> Testing generic 2.6.32 might also be interesting as a datapoint,
>> if you're willing.
> 
> Sorry for the delay, here's the (good) 2.6.32 result:
> 
> # /usr/bin/time bash -c "dd if=/dev/zero of=/mnt/large/10GB bs=1M count=10000 && sync"
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla-daemon | 1 Mar 2010 19:18

[Bug 15420] New: EXT4_USE_FOR_EXT23 causes wrong free space calculation on ext2 and ext3

http://bugzilla.kernel.org/show_bug.cgi?id=15420

           Summary: EXT4_USE_FOR_EXT23 causes wrong free space calculation
                    on ext2 and ext3
           Product: File System
           Version: 2.5
    Kernel Version: 2.6.33
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
        AssignedTo: fs_ext4 <at> kernel-bugs.osdl.org
        ReportedBy: thomas <at> archlinux.org
        Regression: No

When enabling the EXT4_USE_FOR_EXT23 option in 2.6.33. The free space
calculation on ext2 and ext3 becomes incorrect. Steps to reproduce:

1) Create ext2 or ext3 file system with mkfs
2) Mount it on a kernel with EXT4_USE_FOR_EXT23 enabled
3) Launch "watch -n1 df -h /path/to/mountpoint" in another terminal
4) Download a file with wget

The "used space" on the ext2/3 will now increase by about 500MB per second.
Once you stop the download and type "sync" (or wait for a while), the values
shown for free/used space return to expected values. This is always
reproducible.
(Continue reading)

Permalink | Reply | 19 comments |

Gmane