du -s src is a lot slower on SSD than spinning disk in the same laptop

du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

First, I had he problem with btrfs (details below), and then I noticed that
while ext4 is actually twice as fast as btrfs, it's still a lot slower at
stat on my fast Samsung 830 512G SSD than my 1TB laptop hard drive (both
drives being in the same thinkpad T530 with 3.4.4 kernel).

How can things be so slow? 12-13 seconds to scan 15K inodes on a freshly
made filesystem (and 22 secs with btrfs, so at least ext4 wins). The same
thing on my spinning drive takes fewer than 4 seconds, and SSD should be
several times faster than that.
SSD throughput was measured over 400MB/s on the raw device and 268MB/s
through the filesystem:

gandalfthegreat:/mnt/mnt2# du -sh w2k-s002.vmdk
2.0G	w2k-s002.vmdk
gandalfthegreat:/mnt/mnt2# dd if=w2k-s002.vmdk of=/dev/null
2145320960 bytes (2.1 GB) copied, 8.01154 s, 268 MB/s

But stats are just super slow
gandalfthegreat:/mnt/mnt2# time du -sh src/
519M	src/
real	0m12.380s
gandalfthegreat:/mnt/mnt2# reset_cache 
gandalfthegreat:/mnt/mnt2# time bash -c 'find src | wc -l'
15261
real	0m11.612s

Partition was made with:
mkfs.ext4 -O extent -b 4096 -E stride=128,stripe-width=128 /dev/sda2

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x09aaf50a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      502271      250112   83  Linux
/dev/sda2          502272    52930559    26214144   83  Linux << this partition

Details of my btrfs tests below, showing that it's not a problem specific
to ext4.

/dev/sda: Device Model:     SAMSUNG SSD 830 Series
/dev/sda: Firmware Version: CXM03B1Q
/dev/sda: User Capacity:    512,110,190,592 bytes [512 GB]

Any idea what could be going wrong here?

Thanks,
Marc

----- Forwarded message from Marc MERLIN <marc@merlins.org> -----

On an _unencrypted_ partition on the SSD, running du -sh on a directory
with 15K files, takes 23 seconds on unencrypted SSD and 4 secs on
encrypted spinning drive, both with a similar btrfs filesystem, and 
the same kernel (3.4.4).

Unencrypted btrfs on SSD:
gandalfthegreat:~# mount -o compress=lzo,discard,nossd,space_cache,noatime /dev/sda2 /mnt/mnt2
gandalfthegreat:/mnt/mnt2# echo 3 > /proc/sys/vm/drop_caches; time du -sh src
514M	src
real	0m22.667s

Encrypted btrfs on spinning drive of the same src directory:
gandalfthegreat:/var/local# echo 3 > /proc/sys/vm/drop_caches; time du -sh src
514M	src
real	0m3.881s

I've run this many times and get the same numbers.
I've tried deadline and noop on /dev/sda (the SSD) and du is just as slow.  

I also tried with:
- space_cache and nospace_cache
- ssd and nossd
- noatime didn't seem to help even though I was hopeful on this one.

In all cases, I get:
gandalfthegreat:/mnt/mnt2# echo 3 > /proc/sys/vm/drop_caches; time du -sh src
514M	src
real	0m22.537s


I'm having the same slow speed on 2 btrfs filesystems on the same SSD.
One is encrypted, the other one isnt:
Label: 'btrfs_pool1'  uuid: d570c40a-4a0b-4d03-b1c9-cff319fc224d
	Total devices 1 FS bytes used 144.74GB
	devid    1 size 441.70GB used 195.04GB path /dev/dm-0

Label: 'boot'  uuid: 84199644-3542-430a-8f18-a5aa58959662
	Total devices 1 FS bytes used 2.33GB
	devid    1 size 25.00GB used 5.04GB path /dev/sda2

If instead of stating a bunch of files, I try reading a big file, I do get speeds
that are quite fast (253MB/s and 423MB/s).

22 seconds for 15K files on an SSD is super slow and being 5 times
slower than a spinning disk with the same data.
What's going on?

Thanks,
Marc

----- End forwarded message -----

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

On Wed, Jul 25, 2012 at 08:40:28PM +0200, Lukáš Czerner wrote:
> yesterday Milan Broz pointed me to the other problem of yours where
> by reading from dm_crypt target on the SSD was much slower than on
> the spinning disk. I am not sure if he already shared some
> information he managed to gather, but we saw that reading from SSD
> was much slower probably because reads were divided into tons of
> small (page size) bios as opposed to bigger chunks on spinning
> disk.
 
Yes, indeed. To make things simpler, I'm not using dmcrypt here.

> This is probably the same reason here. The reason is most likely
> that we handle SSD differently than spinning disk (turn off
> elevator, different io scheduler and possibly other things I am not
> aware of). Also IIRC bio merging should be less "aggressive" on SSD
> than spinning disk (or maybe even turned off?), because SSD should
> supposedly handle much more iops than than spinning drive, hence
> waiting for a merge might slow things down. However in this case it
> seems to have quite opposite effect for some reason.
> 
> You may try to convince kernel to treat your SSD as rotational disk
> by:
> 
> echo 1 > /sys/block/sda/queue/rotational
> and see if it improves things.

Actually I had done that, along with making the readahead 8K change, but
that didn't help:

gandalfthegreat:/mnt/mnt2# time du -sh src/
519M	src/
real	0m12.176s
gandalfthegreat:/mnt/mnt2# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        25G  3.0G   21G  13% /mnt/mnt2
gandalfthegreat:/mnt/mnt2# blockdev --report /dev/sda2
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw  8192   512  4096     502272     26843283456   /dev/sda2
gandalfthegreat:/mnt/mnt2# cat /sys/block/sda/queue/rotational
1
gandalfthegreat:/mnt/mnt2# 

> Unfortunately I think that there is not much we can do about this
> from the file system level. Someone from block level should
> definitely take a look at this issue. Jens ?

Ok, I just wanted to rule out that it was not a VFS issue.
If you're confident it's block level and basically having storage that is
too fast (and indeed, I just bought one of the fastest SSDs out there) is
actually causing problems that make the entire system much slower as a
result, I'm happy to take it up another list.

Where would you recommend I go with this?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Ted Ts'o]

On Wed, Jul 25, 2012 at 08:40:28PM +0200, Lukáš Czerner wrote:
> > First, I had he problem with btrfs (details below), and then I noticed that
> > while ext4 is actually twice as fast as btrfs, it's still a lot slower at
> > stat on my fast Samsung 830 512G SSD than my 1TB laptop hard drive (both
> > drives being in the same thinkpad T530 with 3.4.4 kernel).
> > 
> > How can things be so slow? 12-13 seconds to scan 15K inodes on a freshly
> > made filesystem (and 22 secs with btrfs, so at least ext4 wins). The same
> > thing on my spinning drive takes fewer than 4 seconds, and SSD should be
> > several times faster than that.
> > SSD throughput was measured over 400MB/s on the raw device and 268MB/s
> > through the filesystem:

Was this an identical file system image on HDD and SSD?

The obvious thing to do is to get a blktrace of du -sh w/ a cold cache
for both the HDD and SSD.  Regardless of whether it's something we can
address at the fs level, or in the block device layer, the blktrace
should make it really clear what is going on.

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

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

On Wed, Jul 25, 2012 at 11:32:23PM -0400, Ted Ts'o wrote:
> On Wed, Jul 25, 2012 at 08:40:28PM +0200, Lukáš Czerner wrote:
> > > First, I had he problem with btrfs (details below), and then I noticed that
> > > while ext4 is actually twice as fast as btrfs, it's still a lot slower at
> > > stat on my fast Samsung 830 512G SSD than my 1TB laptop hard drive (both
> > > drives being in the same thinkpad T530 with 3.4.4 kernel).
> > > 
> > > How can things be so slow? 12-13 seconds to scan 15K inodes on a freshly
> > > made filesystem (and 22 secs with btrfs, so at least ext4 wins). The same
> > > thing on my spinning drive takes fewer than 4 seconds, and SSD should be
> > > several times faster than that.
> > > SSD throughput was measured over 400MB/s on the raw device and 268MB/s
> > > through the filesystem:
> 
> Was this an identical file system image on HDD and SSD?
> 
> The obvious thing to do is to get a blktrace of du -sh w/ a cold cache
> for both the HDD and SSD.  Regardless of whether it's something we can
> address at the fs level, or in the block device layer, the blktrace
> should make it really clear what is going on.

I'm not very familiar with blktrace, but here is one run I did when I was
trying to debug why dd of my dmcrypted FS was running at 27MB/s instead of
270MB/s.
http://marc.merlins.org/tmp/blktrace.txt
(dd shows up as 'bash' for some reason).

If that format isn't good, can you tell me which blktrace command lines I
should use to get you the exact output you'd like?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

On Wed, Jul 25, 2012 at 11:32:23PM -0400, Ted Ts'o wrote:
> On Wed, Jul 25, 2012 at 08:40:28PM +0200, Lukáš Czerner wrote:
> > > First, I had he problem with btrfs (details below), and then I noticed that
> > > while ext4 is actually twice as fast as btrfs, it's still a lot slower at
> > > stat on my fast Samsung 830 512G SSD than my 1TB laptop hard drive (both
> > > drives being in the same thinkpad T530 with 3.4.4 kernel).
> > > 
> > > How can things be so slow? 12-13 seconds to scan 15K inodes on a freshly
> > > made filesystem (and 22 secs with btrfs, so at least ext4 wins). The same
> > > thing on my spinning drive takes fewer than 4 seconds, and SSD should be
> > > several times faster than that.
> > > SSD throughput was measured over 400MB/s on the raw device and 268MB/s
> > > through the filesystem:
> 
> Was this an identical file system image on HDD and SSD?

Not entirely, but I did another test on similar ext4 FS, one on the SSD
and one on th HDD:

gandalfthegreat:/boot# find /boot/src | wc -l
6261
gandalfthegreat:/boot# reset_cache; time du -sh /boot/src ; reset_cache; time du -sh /boot2/src
169M	/boot/src
real	0m5.248s

157M	/boot2/src
real	0m0.698s

gandalfthegreat:/boot# df -h /boot /boot2
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       241M  226M  2.5M  99% /boot
/dev/sdb2       298M  273M  9.3M  97% /boot2
gandalfthegreat:/boot# grep boot /proc/mounts
/dev/sdb2 /boot2 ext4 rw,relatime,stripe=4,data=ordered 0 0
/dev/sda1 /boot ext4 rw,relatime,discard,stripe=32,data=ordered 0 0

The only sizeable difference is that sda1 is a 4K block size I forced to
help with faster writes on the ssd.

In the example above, the SSD is almost 10 times slower than the HDD.

blktrace -d /dev/sda -o - | blkparse -i - during du is 
http://marc.merlins.org/tmp/blktrace_du_sda1.txt

Does that give enough info on what's going on?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

On Wed, Jul 25, 2012 at 11:54:12PM -0700, Marc MERLIN wrote:
> and one on th HDD:
> 
> gandalfthegreat:/boot# find /boot/src | wc -l
> 6261
> gandalfthegreat:/boot# reset_cache; time du -sh /boot/src ; reset_cache; time du -sh /boot2/src
> 169M	/boot/src
> real	0m5.248s
> 
> 157M	/boot2/src
> real	0m0.698s
> 
> gandalfthegreat:/boot# df -h /boot /boot2
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda1       241M  226M  2.5M  99% /boot
> /dev/sdb2       298M  273M  9.3M  97% /boot2
> gandalfthegreat:/boot# grep boot /proc/mounts
> /dev/sdb2 /boot2 ext4 rw,relatime,stripe=4,data=ordered 0 0
> /dev/sda1 /boot ext4 rw,relatime,discard,stripe=32,data=ordered 0 0
> 
> The only sizeable difference is that sda1 is a 4K block size I forced to
> help with faster writes on the ssd.
> 
> In the example above, the SSD is almost 10 times slower than the HDD.
> 
> blktrace -d /dev/sda -o - | blkparse -i - during du is 
> http://marc.merlins.org/tmp/blktrace_du_sda1.txt
> 
> Does that give enough info on what's going on?

(TL;DR: ntfs on linux via fuse is 33% faster than ext4, which is 2x faster
than btrfs, but 3x slower than the same filesystem on spinning disk :( )


Ok, just to help with debuggging this,
1)  I put my samsung 830 SSD into another thinkpad and it wasn't faster or
slower.

2) Then I put a crucial 256 C300 SSD (the replacement for the one I had that
just died and killed all my data), and du took 0.3 seconds on both my old
and new thinkpads.
The old thinkpad is running ubuntu 32bit the new one debian testing 64bit
both with kernel 3.4.4.

So, clearly, there is something wrong with the samsung 830 SSD with linux
but I have no clue what :(
In raw speed (dd) the samsung is faster than the crucial (350MB/s vs
500MB/s).
It it were a random crappy SSD from a random vendor, I'd blame the SSD, but
I have a hard time believing that samsung is selling SSDs that are slower
than hard drives at random IO and 'seeks'.

Mmmh, and to do more tests, I eventually got a 2nd ssd from samsung (same
kind), just to make sure the one I had wasn't bad.

Unfortunately the results are similar.
I upgraded to 3.5.0 in the meantime:

First: btrfs is the slowest:
gandalfthegreat:/mnt/ssd/var/local# time du -sh src/
514M	src/
real	0m25.741s

Second: ext4 with mkfs.ext4 -O extent -b 4096 /dev/sda3
gandalfthegreat:/mnt/mnt3# reset_cache
gandalfthegreat:/mnt/mnt3# time du -sh src/
519M	src/
real	0m12.459s
gandalfthegreat:~# grep mnt3 /proc/mounts
/dev/sda3 /mnt/mnt3 ext4 rw,noatime,discard,data=ordered 0 0

A freshly made ntfs filesystem through fuse is actually FASTER!
gandalfthegreat:/mnt/mnt2# reset_cache 
gandalfthegreat:/mnt/mnt2# time du -sh src/
506M	src/
real	0m8.928s
gandalfthegreat:/mnt/mnt2# grep mnt2 /proc/mounts
/dev/sda2 /mnt/mnt2 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0

How can ntfs via fuse be the fastest?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: How can btrfs take 23sec to stat 23K files from an SSD?

[Marc MERLIN]

On Fri, Jul 27, 2012 at 11:42:39AM -0700, Marc MERLIN wrote:
> > https://oss.oracle.com/~mason/latencytop.patch
> 
> Thanks for the patch, and yes I can confirm I'm definitely not pegged on CPU 
> (not even close and I get the same problem with unencrypted filesystem, actually
> du -sh is exactly the same speed on encrypted and unecrypted).
> 
> Here's the result I think you were looking for. I'm not good at reading this,
> but hopefully it tells you something useful :)
> 
> The full run is here if that helps:
> http://marc.merlins.org/tmp/latencytop.txt
 
I did some other tests since last week since my laptop is hard to use
considering how slow the SSD is.

(TL;DR: ntfs on linux via fuse is 33% faster than ext4, which is 2x faster
than btrfs, but 3x slower than the same filesystem on spinning disk :( )


Ok, just to help with debuggging this,
1)  I put my samsung 830 SSD into another thinkpad and it wasn't faster or
slower.

2) Then I put a crucial 256 C300 SSD (the replacement for the one I had that
just died and killed all my data), and du took 0.3 seconds on both my old
and new thinkpads.
The old thinkpad is running ubuntu 32bit the new one debian testing 64bit
both with kernel 3.4.4.

So, clearly, there is something wrong with the samsung 830 SSD with linux
but I have no clue what :(
In raw speed (dd) the samsung is faster than the crucial (350MB/s vs
500MB/s).
It it were a random crappy SSD from a random vendor, I'd blame the SSD, but
I have a hard time believing that samsung is selling SSDs that are slower
than hard drives at random IO and 'seeks'.

3) I just got a 2nd ssd from samsung (same kind), just to make sure the one
I had wasn't bad. It's brand new, and I formatted it carefully on 512
boundaries:
/dev/sda1            2048      502271      250112   83  Linux
/dev/sda2          502272    52930559    26214144    7  HPFS/NTFS/exFAT
/dev/sda3        52930560    73902079    10485760   82  Linux swap / Solaris
/dev/sda4        73902080  1000215215   463156568   83  Linux

I also upgraded to 3.5.0 in the meantime but unfortunately the results are
similar.

First: btrfs is the slowest:
gandalfthegreat:/mnt/ssd/var/local# time du -sh src/
514M	src/
real	0m25.741s
gandalfthegreat:/mnt/ssd/var/local# grep /mnt/ssd/var /proc/mounts 
/dev/mapper/ssd /mnt/ssd/var btrfs rw,noatime,compress=lzo,ssd,discard,space_cache 0 0


Second: ext4 is 2x faster than btrfs with mkfs.ext4 -O extent -b 4096 /dev/sda3
gandalfthegreat:/mnt/mnt3# reset_cache
gandalfthegreat:/mnt/mnt3# time du -sh src/
519M	src/
real	0m12.459s
gandalfthegreat:~# grep mnt3 /proc/mounts
/dev/sda3 /mnt/mnt3 ext4 rw,noatime,discard,data=ordered 0 0

Third, A freshly made ntfs filesystem through fuse is actually FASTER!
gandalfthegreat:/mnt/mnt2# reset_cache 
gandalfthegreat:/mnt/mnt2# time du -sh src/
506M	src/
real	0m8.928s
gandalfthegreat:/mnt/mnt2# grep mnt2 /proc/mounts
/dev/sda2 /mnt/mnt2 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0

How can ntfs via fuse be the fastest and btrfs so slow?
Of course, all 3 are slower than the same filesystem on spinning too, but
I'm wondering if there is a scheduling issue that is somehow causing the
extreme slowness I'm seeing.

Did the latencytop trace I got help in any way?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: How can btrfs take 23sec to stat 23K files from an SSD?

[Chris Samuel]

On 01/08/12 16:01, Marc MERLIN wrote:

> Third, A freshly made ntfs filesystem through fuse is actually FASTER!

Could it be that Samsungs FTL has optimisations in it for NTFS ?

A horrible thought, but not impossible..

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

Re: How can btrfs take 23sec to stat 23K files from an SSD?

[Marc MERLIN]

On Wed, Aug 01, 2012 at 04:36:22PM +1000, Chris Samuel wrote:
> On 01/08/12 16:01, Marc MERLIN wrote:
> 
> > Third, A freshly made ntfs filesystem through fuse is actually FASTER!
> 
> Could it be that Samsungs FTL has optimisations in it for NTFS ?
> 
> A horrible thought, but not impossible..

Not impossible, but it's can be the main reason since it clocks still 2x
slower with ntfs than a spinning disk with encrypted btrfs.
Since SSDs should "seek" 10-100x faster than spinning disks, that can't be
the only reason.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Spelic]

On 08/01/12 07:30, Marc MERLIN wrote:
> 2) Then I put a crucial 256 C300 SSD (the replacement for the one I 
> had that just died and killed all my data), and du took 0.3 seconds on 
> both my old and new thinkpads. 


What does FIO say on your Samsung 830 SSD, 4k random reads?
Last time I checked online benchmarks Samsung 830 had very good 4k 
random reads, but it's difficult to find online benchmarks for 
incompressible data (which fio rightly uses btw)

multithreded test:
vi fiotest_mt.fio
         [random-read]
         rw=randread
         numjobs=20
         thread
         iodepth=10
         group_reporting
         blocksize=4k
         size=512m
         directory=/mnt/<yourmountpoint>
         end_fsync=1
         runtime=10

and single threaded (more important here):
vi fiotest_st.fio
         [random-read]
         rw=randread
         numjobs=1
         thread
         iodepth=1
         group_reporting
         blocksize=4k
         size=4g
         directory=/mnt/<yourmountpoint>
         end_fsync=1
         runtime=10

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

On Tue, Jul 31, 2012 at 10:30:42PM -0700, Marc MERLIN wrote:
> First: btrfs is the slowest:
> gandalfthegreat:/mnt/ssd/var/local# time du -sh src/
> 514M	src/
> real	0m25.741s
> 
> Second: ext4 with mkfs.ext4 -O extent -b 4096 /dev/sda3
> gandalfthegreat:/mnt/mnt3# reset_cache
> gandalfthegreat:/mnt/mnt3# time du -sh src/
> 519M	src/
> real	0m12.459s
> gandalfthegreat:~# grep mnt3 /proc/mounts
> /dev/sda3 /mnt/mnt3 ext4 rw,noatime,discard,data=ordered 0 0
> 
> A freshly made ntfs filesystem through fuse is actually FASTER!
> gandalfthegreat:/mnt/mnt2# reset_cache 
> gandalfthegreat:/mnt/mnt2# time du -sh src/
> 506M	src/
> real	0m8.928s
> gandalfthegreat:/mnt/mnt2# grep mnt2 /proc/mounts
> /dev/sda2 /mnt/mnt2 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
> 
> How can ntfs via fuse be the fastest?

To provide closure to this thread.

I owed everyone an update, which I just finished typing:
http://marc.merlins.org/perso/linux/post_2012-08-15_The-tale-of-SSDs_-Crucial-C300-early-Death_-Samsung-830-extreme-random-IO-slowness_-and-settling-with-OCZ-Vertex-4.html

Basically, the samsung 830 just sucks. I got 2 of them, they both utterly
sucked. There is no excuse for an SSD being several times slower than a slow
hard drive on _READs_ (not even talking about writes).

I'm not sure how I could have gotten 2 bad drives from Samsung in 2
different shipments, so I'm afraid the entire line may be bad. At least, it
was for me after extensive benchmarking, and even using their own windows
benchmarking tool.

In the end, I got a OCZ Vertex 4 and it's superfast as per the benchmarks I
posted in the link above.

As good news, ext4 is faster than btrfs in my (limited) tests across both
SSDs and my hard drive.

Cheers,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Marc MERLIN]

On Thu, Aug 16, 2012 at 11:51:30AM +0200, Spelic wrote:
> On 08/16/12 09:50, Marc MERLIN wrote:
> >On Tue, Jul 31, 2012 at 10:30:42PM -0700, Marc MERLIN wrote:
> >>How can ntfs via fuse be the fastest?
> >To provide closure to this thread.
> >
> >I owed everyone an update, which I just finished typing:
> >http://marc.merlins.org/perso/linux/post_2012-08-15_The-tale-of-SSDs_-Crucial-C300-early-Death_-Samsung-830-extreme-random-IO-slowness_-and-settling-with-OCZ-Vertex-4.html
> 
> Hello,
> reading your article a few ideas came to my mind.
> 
> Firstly, for the Crucial, I haven't read much about that bug, but would 
> leaving the last 20% of the drive free (make an empty partition there 
> and then fstrim it and leave it empty) help with that bug? Maybe the 
> garbage collection algorithm hasn't got enough free blocks to shuffle 
> data around. I am interested because Crucial would be my prime choice 
> for what I read around. When it resuscitated did you try to TRIM it 
> wholly to try regain performances? I don't know if you still have it around.
 
The drive was still mostly dead, it didn't work long enough for me to try to
reformat it. I RMA'ed it and haven't used the replacement yet because I
don't have data I don't care about enough :)

> Secondly, for the Samsung 830:
> The random access slowness is reproducible also without dm-crypt it 
> seems to me. This benchmark of yours was NOT on dm-crypt, correct?
> http://www.spinics.net/lists/linux-btrfs/msg18238.html

Correct.

> In your  fio benchmarks, e.g.
> http://www.spinics.net/lists/linux-btrfs/msg18204.html
> I noticed how the iodepth is at 64
> 
> The Samsung SSD has a bug on high IO depths:
> 
> http://www.bit-tech.net/hardware/2011/09/29/samsung-ssd-830-256gb-review/3
> http://www.bit-tech.net/hardware/2011/09/29/samsung-ssd-830-256gb-review/5
> already at 32 behaves bad.
> 
> Please do
> echo 1 > /sys/block/sdX/device/queue_depth
 
Sorry, I don't have the drives anymore, so I can't, but between you and me
if the drive fails to perform after as much work I put in it, as in its
default configuration on windows 7, that's pretty damn sad.

Point being that those things should kind of "just work", like the Crucial
(before sudden death) and the OCZ.
I spent too many hours of my life trying to get the damn drive to perform,
and if it takes even more kernel and IO experts to kind of get the drive to
work (assuming it would have, and at this point I'm not certain), then it's
crap in my book (also you can't tune half that stuff on windows for the
primary users who would buy that drive).

You are welcome to order one though and try your own tests and post them
here. Worst case, you can return it if it sucks for you too.

I just added the screeshot of the windows benchmarks if that helps.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

ext4 crash with 3.5.2 in ext4_ext_remove_space

[Marc MERLIN]

I get a crash when mounting a filesystem.
I'm making an image now with e2image -r before I run e2fsck on it.

Is there anything else you'd like me to do?

[13090.175424] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[13090.184897] IP: [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
[13090.192927] PGD 1120d7067 PUD 1123ac067 PMD 0 
[13090.198469] Oops: 0000 [#1] PREEMPT SMP 
[13090.203508] CPU 1 
[13090.205368] Modules linked in:[13090.209508]  ppdev lp tun autofs4 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx sata_mv kl5kusb105 ftdi_sio keyspan nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_state xt_tcpudp xt_LOG iptable_mangle iptable_filter deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 lrw serpent_generic xts gf128mul cast5 des_generic xcbc rmd160 sha512_generic crypto_null af_key xfrm_algo blowfish_generic blowfish_x86_64 blowfish_common dm_crypt dm_mirror dm_region_hash dm_log aes_x86_64 fuse lm85 hwmon_vid dm_snapshot dm_mod iptable_nat ip_tables nf_conntrack_ftp ipt_MASQUERADE nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 x_tables nf_conntrack sg 
 st snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek rc_ati_x10 ati_remote rc_core pl2303 usbserial i915 snd_hda_intel snd_cmipci snd_hda_codec gameport drm_kms_helper drm snd_opl3_lib snd_mpu401_uart eeepc_wmi asus_wmi
 i2c_algo_bit[13090.315877]  sparse_keymap rfkill snd_hwdep snd_seq_midi acpi_cpufreq snd_seq_midi_event mperf kvm_intel kvm processor snd_seq snd_pcm pci_hotplug ehci_hcd wmi parport_pc xhci_hcd microcode button video sata_sil24 parport snd_rawmidi snd_timer usbcore crc32c_intel ghash_clmulni_intel i2c_i801 snd_seq_device cryptd evdev snd lpc_ich mei i2c_core pcspkr snd_page_alloc thermal_sys usb_common soundcore coretemp r8169 mii tpm_tis tpm tpm_bios [last unloaded: kl5kusb105]

[13090.370146] Pid: 9658, comm: mount Not tainted 3.5.2-amd64-preempt-noide-20120903 #1 System manufacturer System Product Name/P8H67-M PRO
[13090.387559] RIP: 0010:[<ffffffff8119b92f>]  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
[13090.398254] RSP: 0018:ffff88012b4c7a18  EFLAGS: 00010246
[13090.406241] RAX: 0000000000000000 RBX: ffff8800a41fb4e8 RCX: ffff8800a41fb450
[13090.416102] RDX: 0000000000000001 RSI: 0000000000000002 RDI: 000000001b340000
[13090.426003] RBP: ffff88012b4c7af8 R08: 000000001b340000 R09: ffff88008ae6f6e0
[13090.435920] R10: ffff880000000000 R11: 0000000000000000 R12: ffff8801156e86f0
[13090.445782] R13: 0000000000000000 R14: ffff8801156e86c0 R15: 0000000000000000
[13090.455627] FS:  0000000000000000(0000) GS:ffff88013fa80000(0063) knlGS:00000000f75ae750
[13090.466451] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
[13090.475010] CR2: 0000000000000028 CR3: 0000000115614000 CR4: 00000000000407e0
[13090.484921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[13090.494802] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[13090.504649] Process mount (pid: 9658, threadinfo ffff88012b4c6000, task ffff88008d91c4c0)
[13090.515567] Stack:
[13090.520209]  ffff88012b4c7a28 ffffffff81175f65 ffff88012b4c7a88 ffffffff81179c44
[13090.530426]  ffff880100001000 00000000fffffff5 ffffffffa41fb438 ffff8801156e8748
[13090.540694]  00000000000a77ff ffff8800a41fb438 0000000008007800 ffff880122e67800
[13090.551124] Call Trace:
[13090.556238]  [<ffffffff81175f65>] ? brelse+0xe/0x10
[13090.564018]  [<ffffffff81179c44>] ? ext4_mark_iloc_dirty+0x51c/0x581
[13090.573175]  [<ffffffff8119d51c>] ext4_ext_truncate+0xcd/0x179
[13090.581856]  [<ffffffff81132b1c>] ? __inode_wait_for_writeback+0x67/0xa9
[13090.591316]  [<ffffffff81177e74>] ext4_truncate+0x9c/0xdf
[13090.599434]  [<ffffffff8117b721>] ext4_evict_inode+0x1e9/0x2d6
[13090.608273]  [<ffffffff811282e3>] evict+0xa8/0x162
[13090.615846]  [<ffffffff81128588>] iput+0x1b3/0x1bb
[13090.623284]  [<ffffffff8119570d>] ext4_fill_super+0x214b/0x256b
[13090.631785]  [<ffffffff8128f835>] ? vsnprintf+0x1ce/0x421
[13090.639778]  [<ffffffff8113f9b2>] ? set_blocksize+0x36/0x86
[13090.647864]  [<ffffffff811169ae>] mount_bdev+0x14b/0x1ad
[13090.655707]  [<ffffffff811935c2>] ? ext4_calculate_overhead+0x247/0x247
[13090.664876]  [<ffffffff8112ada7>] ? alloc_vfsmnt+0xa6/0x198
[13090.672989]  [<ffffffff81184d5f>] ext4_mount+0x10/0x12
[13090.680564]  [<ffffffff81117390>] mount_fs+0x64/0x150
[13090.687944]  [<ffffffff810e5439>] ? __alloc_percpu+0xb/0xd
[13090.695702]  [<ffffffff8112b156>] vfs_kern_mount+0x64/0xde
[13090.703435]  [<ffffffff8112b544>] do_kern_mount+0x48/0xda
[13090.711023]  [<ffffffff8112ce32>] do_mount+0x6a1/0x704
[13090.718294]  [<ffffffff810e1181>] ? memdup_user+0x38/0x60
[13090.725767]  [<ffffffff810e11df>] ? strndup_user+0x36/0x4c
[13090.733260]  [<ffffffff8114ffaa>] compat_sys_mount+0x208/0x242
[13090.741047]  [<ffffffff814b0b06>] sysenter_dispatch+0x7/0x21
[13090.748612] Code: ff 4c 63 65 b8 4d 6b e4 30 4c 03 65 b0 e9 fd 00 00 00 48 63 55 b8 4c 6b e2 30 4c 03 65 b0 49 83 7c 24 20 00 75 0e 49 8b 44 24 28 <48> 8b 40 28 49 89 44 24 20 49 8b 44 24 18 48 85 c0 75 22 49 8b 
[13090.772841] RIP  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
[13090.781438]  RSP <ffff88012b4c7a18>
[13090.786758] CR2: 0000000000000028
[13090.804674] ---[ end trace 880c73500bb7f09f ]---
[13090.810808] Kernel panic - not syncing: Fatal exception
[13090.817346] panic occurred, switching back to text console
[13090.824556] Rebooting in 20 seconds..
[13110.758740] ACPI MEMORY or I/O RESET_REG.
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: ext4 crash with 3.5.2 in ext4_ext_remove_space

[Lukáš Czerner]

Hi,

I believe that this has been fixed with v3.6-rc1-5-g89a4e48 and it
was marked for stable release as well.

-Lukas

On Wed, 5 Sep 2012, Marc MERLIN wrote:

> Date: Wed, 5 Sep 2012 09:52:10 -0700
> From: Marc MERLIN <marc@merlins.org>
> To: linux-ext4@vger.kernel.org
> Subject: ext4 crash with 3.5.2 in ext4_ext_remove_space
> 
> I get a crash when mounting a filesystem.
> I'm making an image now with e2image -r before I run e2fsck on it.
> 
> Is there anything else you'd like me to do?
> 
> [13090.175424] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> [13090.184897] IP: [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> [13090.192927] PGD 1120d7067 PUD 1123ac067 PMD 0 
> [13090.198469] Oops: 0000 [#1] PREEMPT SMP 
> [13090.203508] CPU 1 
> [13090.205368] Modules linked in:[13090.209508]  ppdev lp tun autofs4 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx sata_mv kl5kusb105 ftdi_sio keyspan nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_state xt_tcpudp xt_LOG iptable_mangle iptable_filter deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 lrw serpent_generic xts gf128mul cast5 des_generic xcbc rmd160 sha512_generic crypto_null af_key xfrm_algo blowfish_generic blowfish_x86_64 blowfish_common dm_crypt dm_mirror dm_region_hash dm_log aes_x86_64 fuse lm85 hwmon_vid dm_snapshot dm_mod iptable_nat ip_tables nf_conntrack_ftp ipt_MASQUERADE nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 x_tables nf_conntrack s
 g st snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek rc_ati_x10 ati_remote rc_core pl2303 usbserial i915 snd_hda_intel snd_cmipci snd_hda_codec gameport drm_kms_helper dr!
 m !
>  snd_opl3_lib snd_mpu401_uart eeepc_wmi asus_wmi
>  i2c_algo_bit[13090.315877]  sparse_keymap rfkill snd_hwdep snd_seq_midi acpi_cpufreq snd_seq_midi_event mperf kvm_intel kvm processor snd_seq snd_pcm pci_hotplug ehci_hcd wmi parport_pc xhci_hcd microcode button video sata_sil24 parport snd_rawmidi snd_timer usbcore crc32c_intel ghash_clmulni_intel i2c_i801 snd_seq_device cryptd evdev snd lpc_ich mei i2c_core pcspkr snd_page_alloc thermal_sys usb_common soundcore coretemp r8169 mii tpm_tis tpm tpm_bios [last unloaded: kl5kusb105]
> 
> [13090.370146] Pid: 9658, comm: mount Not tainted 3.5.2-amd64-preempt-noide-20120903 #1 System manufacturer System Product Name/P8H67-M PRO
> [13090.387559] RIP: 0010:[<ffffffff8119b92f>]  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> [13090.398254] RSP: 0018:ffff88012b4c7a18  EFLAGS: 00010246
> [13090.406241] RAX: 0000000000000000 RBX: ffff8800a41fb4e8 RCX: ffff8800a41fb450
> [13090.416102] RDX: 0000000000000001 RSI: 0000000000000002 RDI: 000000001b340000
> [13090.426003] RBP: ffff88012b4c7af8 R08: 000000001b340000 R09: ffff88008ae6f6e0
> [13090.435920] R10: ffff880000000000 R11: 0000000000000000 R12: ffff8801156e86f0
> [13090.445782] R13: 0000000000000000 R14: ffff8801156e86c0 R15: 0000000000000000
> [13090.455627] FS:  0000000000000000(0000) GS:ffff88013fa80000(0063) knlGS:00000000f75ae750
> [13090.466451] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> [13090.475010] CR2: 0000000000000028 CR3: 0000000115614000 CR4: 00000000000407e0
> [13090.484921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [13090.494802] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [13090.504649] Process mount (pid: 9658, threadinfo ffff88012b4c6000, task ffff88008d91c4c0)
> [13090.515567] Stack:
> [13090.520209]  ffff88012b4c7a28 ffffffff81175f65 ffff88012b4c7a88 ffffffff81179c44
> [13090.530426]  ffff880100001000 00000000fffffff5 ffffffffa41fb438 ffff8801156e8748
> [13090.540694]  00000000000a77ff ffff8800a41fb438 0000000008007800 ffff880122e67800
> [13090.551124] Call Trace:
> [13090.556238]  [<ffffffff81175f65>] ? brelse+0xe/0x10
> [13090.564018]  [<ffffffff81179c44>] ? ext4_mark_iloc_dirty+0x51c/0x581
> [13090.573175]  [<ffffffff8119d51c>] ext4_ext_truncate+0xcd/0x179
> [13090.581856]  [<ffffffff81132b1c>] ? __inode_wait_for_writeback+0x67/0xa9
> [13090.591316]  [<ffffffff81177e74>] ext4_truncate+0x9c/0xdf
> [13090.599434]  [<ffffffff8117b721>] ext4_evict_inode+0x1e9/0x2d6
> [13090.608273]  [<ffffffff811282e3>] evict+0xa8/0x162
> [13090.615846]  [<ffffffff81128588>] iput+0x1b3/0x1bb
> [13090.623284]  [<ffffffff8119570d>] ext4_fill_super+0x214b/0x256b
> [13090.631785]  [<ffffffff8128f835>] ? vsnprintf+0x1ce/0x421
> [13090.639778]  [<ffffffff8113f9b2>] ? set_blocksize+0x36/0x86
> [13090.647864]  [<ffffffff811169ae>] mount_bdev+0x14b/0x1ad
> [13090.655707]  [<ffffffff811935c2>] ? ext4_calculate_overhead+0x247/0x247
> [13090.664876]  [<ffffffff8112ada7>] ? alloc_vfsmnt+0xa6/0x198
> [13090.672989]  [<ffffffff81184d5f>] ext4_mount+0x10/0x12
> [13090.680564]  [<ffffffff81117390>] mount_fs+0x64/0x150
> [13090.687944]  [<ffffffff810e5439>] ? __alloc_percpu+0xb/0xd
> [13090.695702]  [<ffffffff8112b156>] vfs_kern_mount+0x64/0xde
> [13090.703435]  [<ffffffff8112b544>] do_kern_mount+0x48/0xda
> [13090.711023]  [<ffffffff8112ce32>] do_mount+0x6a1/0x704
> [13090.718294]  [<ffffffff810e1181>] ? memdup_user+0x38/0x60
> [13090.725767]  [<ffffffff810e11df>] ? strndup_user+0x36/0x4c
> [13090.733260]  [<ffffffff8114ffaa>] compat_sys_mount+0x208/0x242
> [13090.741047]  [<ffffffff814b0b06>] sysenter_dispatch+0x7/0x21
> [13090.748612] Code: ff 4c 63 65 b8 4d 6b e4 30 4c 03 65 b0 e9 fd 00 00 00 48 63 55 b8 4c 6b e2 30 4c 03 65 b0 49 83 7c 24 20 00 75 0e 49 8b 44 24 28 <48> 8b 40 28 49 89 44 24 20 49 8b 44 24 18 48 85 c0 75 22 49 8b 
> [13090.772841] RIP  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> [13090.781438]  RSP <ffff88012b4c7a18>
> [13090.786758] CR2: 0000000000000028
> [13090.804674] ---[ end trace 880c73500bb7f09f ]---
> [13090.810808] Kernel panic - not syncing: Fatal exception
> [13090.817346] panic occurred, switching back to text console
> [13090.824556] Rebooting in 20 seconds..
> [13110.758740] ACPI MEMORY or I/O RESET_REG.
> 

Re: ext4 crash with 3.5.2 in ext4_ext_remove_space

[Marc MERLIN]

On Wed, Sep 05, 2012 at 01:50:54PM -0400, Lukáš Czerner wrote:
> Hi,
> 
> I believe that this has been fixed with v3.6-rc1-5-g89a4e48 and it
> was marked for stable release as well.

Cool, thanks for letting me know.

I'll keep the e2image on hand just in case, and just fsck the filesystem
before mounting it.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ext4 crash with 3.5.2 in ext4_ext_remove_space

[Marc MERLIN]

On Wed, Sep 05, 2012 at 01:50:54PM -0400, Lukáš Czerner wrote:
> Hi,
> 
> I believe that this has been fixed with v3.6-rc1-5-g89a4e48 and it
> was marked for stable release as well.

If that helps, it was indeed a single orphaned inode. After clearing it, 
I was able to mount the partition without problems.

gargamel:~# e2fsck -y /dev/mapper/dshelf2-space
e2fsck 1.42.5 (29-Jul-2012)
/dev/mapper/dshelf2-space: recovering journal
Clearing orphaned inode 92668757 (uid=1002, gid=8, mode=0100660, size=6574695342)
/dev/mapper/dshelf2-space: clean, 16987882/114098176 files, 426716110/456392704 blocks

Cheers,
Marc

> -Lukas
> 
> On Wed, 5 Sep 2012, Marc MERLIN wrote:
> 
> > Date: Wed, 5 Sep 2012 09:52:10 -0700
> > From: Marc MERLIN <marc@merlins.org>
> > To: linux-ext4@vger.kernel.org
> > Subject: ext4 crash with 3.5.2 in ext4_ext_remove_space
> > 
> > I get a crash when mounting a filesystem.
> > I'm making an image now with e2image -r before I run e2fsck on it.
> > 
> > Is there anything else you'd like me to do?
> > 
> > [13090.175424] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> > [13090.184897] IP: [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > [13090.192927] PGD 1120d7067 PUD 1123ac067 PMD 0 
> > [13090.198469] Oops: 0000 [#1] PREEMPT SMP 
> > [13090.203508] CPU 1 
> > [13090.205368] Modules linked in:[13090.209508]  ppdev lp tun autofs4 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx sata_mv kl5kusb105 ftdi_sio keyspan nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_state xt_tcpudp xt_LOG iptable_mangle iptable_filter deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 lrw serpent_generic xts gf128mul cast5 des_generic xcbc rmd160 sha512_generic crypto_null af_key xfrm_algo blowfish_generic blowfish_x86_64 blowfish_common dm_crypt dm_mirror dm_region_hash dm_log aes_x86_64 fuse lm85 hwmon_vid dm_snapshot dm_mod iptable_nat ip_tables nf_conntrack_ftp ipt_MASQUERADE nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek rc_ati_x10 ati_remote rc_core pl2303 usbserial i915 snd_hda_intel snd_cmipci snd_hda_codec gameport drm_kms_helper dr!
>  m !
> >  snd_opl3_lib snd_mpu401_uart eeepc_wmi asus_wmi
> >  i2c_algo_bit[13090.315877]  sparse_keymap rfkill snd_hwdep snd_seq_midi acpi_cpufreq snd_seq_midi_event mperf kvm_intel kvm processor snd_seq snd_pcm pci_hotplug ehci_hcd wmi parport_pc xhci_hcd microcode button video sata_sil24 parport snd_rawmidi snd_timer usbcore crc32c_intel ghash_clmulni_intel i2c_i801 snd_seq_device cryptd evdev snd lpc_ich mei i2c_core pcspkr snd_page_alloc thermal_sys usb_common soundcore coretemp r8169 mii tpm_tis tpm tpm_bios [last unloaded: kl5kusb105]
> > 
> > [13090.370146] Pid: 9658, comm: mount Not tainted 3.5.2-amd64-preempt-noide-20120903 #1 System manufacturer System Product Name/P8H67-M PRO
> > [13090.387559] RIP: 0010:[<ffffffff8119b92f>]  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > [13090.398254] RSP: 0018:ffff88012b4c7a18  EFLAGS: 00010246
> > [13090.406241] RAX: 0000000000000000 RBX: ffff8800a41fb4e8 RCX: ffff8800a41fb450
> > [13090.416102] RDX: 0000000000000001 RSI: 0000000000000002 RDI: 000000001b340000
> > [13090.426003] RBP: ffff88012b4c7af8 R08: 000000001b340000 R09: ffff88008ae6f6e0
> > [13090.435920] R10: ffff880000000000 R11: 0000000000000000 R12: ffff8801156e86f0
> > [13090.445782] R13: 0000000000000000 R14: ffff8801156e86c0 R15: 0000000000000000
> > [13090.455627] FS:  0000000000000000(0000) GS:ffff88013fa80000(0063) knlGS:00000000f75ae750
> > [13090.466451] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> > [13090.475010] CR2: 0000000000000028 CR3: 0000000115614000 CR4: 00000000000407e0
> > [13090.484921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [13090.494802] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [13090.504649] Process mount (pid: 9658, threadinfo ffff88012b4c6000, task ffff88008d91c4c0)
> > [13090.515567] Stack:
> > [13090.520209]  ffff88012b4c7a28 ffffffff81175f65 ffff88012b4c7a88 ffffffff81179c44
> > [13090.530426]  ffff880100001000 00000000fffffff5 ffffffffa41fb438 ffff8801156e8748
> > [13090.540694]  00000000000a77ff ffff8800a41fb438 0000000008007800 ffff880122e67800
> > [13090.551124] Call Trace:
> > [13090.556238]  [<ffffffff81175f65>] ? brelse+0xe/0x10
> > [13090.564018]  [<ffffffff81179c44>] ? ext4_mark_iloc_dirty+0x51c/0x581
> > [13090.573175]  [<ffffffff8119d51c>] ext4_ext_truncate+0xcd/0x179
> > [13090.581856]  [<ffffffff81132b1c>] ? __inode_wait_for_writeback+0x67/0xa9
> > [13090.591316]  [<ffffffff81177e74>] ext4_truncate+0x9c/0xdf
> > [13090.599434]  [<ffffffff8117b721>] ext4_evict_inode+0x1e9/0x2d6
> > [13090.608273]  [<ffffffff811282e3>] evict+0xa8/0x162
> > [13090.615846]  [<ffffffff81128588>] iput+0x1b3/0x1bb
> > [13090.623284]  [<ffffffff8119570d>] ext4_fill_super+0x214b/0x256b
> > [13090.631785]  [<ffffffff8128f835>] ? vsnprintf+0x1ce/0x421
> > [13090.639778]  [<ffffffff8113f9b2>] ? set_blocksize+0x36/0x86
> > [13090.647864]  [<ffffffff811169ae>] mount_bdev+0x14b/0x1ad
> > [13090.655707]  [<ffffffff811935c2>] ? ext4_calculate_overhead+0x247/0x247
> > [13090.664876]  [<ffffffff8112ada7>] ? alloc_vfsmnt+0xa6/0x198
> > [13090.672989]  [<ffffffff81184d5f>] ext4_mount+0x10/0x12
> > [13090.680564]  [<ffffffff81117390>] mount_fs+0x64/0x150
> > [13090.687944]  [<ffffffff810e5439>] ? __alloc_percpu+0xb/0xd
> > [13090.695702]  [<ffffffff8112b156>] vfs_kern_mount+0x64/0xde
> > [13090.703435]  [<ffffffff8112b544>] do_kern_mount+0x48/0xda
> > [13090.711023]  [<ffffffff8112ce32>] do_mount+0x6a1/0x704
> > [13090.718294]  [<ffffffff810e1181>] ? memdup_user+0x38/0x60
> > [13090.725767]  [<ffffffff810e11df>] ? strndup_user+0x36/0x4c
> > [13090.733260]  [<ffffffff8114ffaa>] compat_sys_mount+0x208/0x242
> > [13090.741047]  [<ffffffff814b0b06>] sysenter_dispatch+0x7/0x21
> > [13090.748612] Code: ff 4c 63 65 b8 4d 6b e4 30 4c 03 65 b0 e9 fd 00 00 00 48 63 55 b8 4c 6b e2 30 4c 03 65 b0 49 83 7c 24 20 00 75 0e 49 8b 44 24 28 <48> 8b 40 28 49 89 44 24 20 49 8b 44 24 18 48 85 c0 75 22 49 8b 
> > [13090.772841] RIP  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > [13090.781438]  RSP <ffff88012b4c7a18>
> > [13090.786758] CR2: 0000000000000028
> > [13090.804674] ---[ end trace 880c73500bb7f09f ]---
> > [13090.810808] Kernel panic - not syncing: Fatal exception
> > [13090.817346] panic occurred, switching back to text console
> > [13090.824556] Rebooting in 20 seconds..
> > [13110.758740] ACPI MEMORY or I/O RESET_REG.
> > 
> 

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ext4 crash with 3.5.2 in ext4_ext_remove_space

[Marc MERLIN]

On Wed, Sep 05, 2012 at 09:24:26PM -0700, Marc MERLIN wrote:
> On Wed, Sep 05, 2012 at 01:50:54PM -0400, Lukáš Czerner wrote:
> > Hi,
> > 
> > I believe that this has been fixed with v3.6-rc1-5-g89a4e48 and it
> > was marked for stable release as well.
> 
> If that helps, it was indeed a single orphaned inode. After clearing it, 
> I was able to mount the partition without problems.
> 
> gargamel:~# e2fsck -y /dev/mapper/dshelf2-space
> e2fsck 1.42.5 (29-Jul-2012)
> /dev/mapper/dshelf2-space: recovering journal
> Clearing orphaned inode 92668757 (uid=1002, gid=8, mode=0100660, size=6574695342)
> /dev/mapper/dshelf2-space: clean, 16987882/114098176 files, 426716110/456392704 blocks

Would you happen to have a link to the patch, I had this crash again, I'd
like to check if it's in 3.5.3 or apply it myself to stop further crashes.

Thanks,
Marc
 
> Cheers,
> Marc
> 
> > -Lukas
> > 
> > On Wed, 5 Sep 2012, Marc MERLIN wrote:
> > 
> > > Date: Wed, 5 Sep 2012 09:52:10 -0700
> > > From: Marc MERLIN <marc@merlins.org>
> > > To: linux-ext4@vger.kernel.org
> > > Subject: ext4 crash with 3.5.2 in ext4_ext_remove_space
> > > 
> > > I get a crash when mounting a filesystem.
> > > I'm making an image now with e2image -r before I run e2fsck on it.
> > > 
> > > Is there anything else you'd like me to do?
> > > 
> > > [13090.175424] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> > > [13090.184897] IP: [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > > [13090.192927] PGD 1120d7067 PUD 1123ac067 PMD 0 
> > > [13090.198469] Oops: 0000 [#1] PREEMPT SMP 
> > > [13090.203508] CPU 1 
> > > [13090.205368] Modules linked in:[13090.209508]  ppdev lp tun autofs4 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx sata_mv kl5kusb105 ftdi_sio keyspan nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_state xt_tcpudp xt_LOG iptable_mangle iptable_filter deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 lrw serpent_generic xts gf128mul cast5 des_generic xcbc rmd160 sha512_generic crypto_null af_key xfrm_algo blowfish_generic blowfish_x86_64 blowfish_common dm_crypt dm_mirror dm_region_hash dm_log aes_x86_64 fuse lm85 hwmon_vid dm_snapshot dm_mod iptable_nat ip_tables nf_conntrack_ftp ipt_MASQUERADE nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek rc_ati_x10 ati_remote rc_core pl2303 usbserial i915 snd_hda_intel snd_cmipci snd_hda_codec gameport drm_kms_helper dr!
> >  m !
> > >  snd_opl3_lib snd_mpu401_uart eeepc_wmi asus_wmi
> > >  i2c_algo_bit[13090.315877]  sparse_keymap rfkill snd_hwdep snd_seq_midi acpi_cpufreq snd_seq_midi_event mperf kvm_intel kvm processor snd_seq snd_pcm pci_hotplug ehci_hcd wmi parport_pc xhci_hcd microcode button video sata_sil24 parport snd_rawmidi snd_timer usbcore crc32c_intel ghash_clmulni_intel i2c_i801 snd_seq_device cryptd evdev snd lpc_ich mei i2c_core pcspkr snd_page_alloc thermal_sys usb_common soundcore coretemp r8169 mii tpm_tis tpm tpm_bios [last unloaded: kl5kusb105]
> > > 
> > > [13090.370146] Pid: 9658, comm: mount Not tainted 3.5.2-amd64-preempt-noide-20120903 #1 System manufacturer System Product Name/P8H67-M PRO
> > > [13090.387559] RIP: 0010:[<ffffffff8119b92f>]  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > > [13090.398254] RSP: 0018:ffff88012b4c7a18  EFLAGS: 00010246
> > > [13090.406241] RAX: 0000000000000000 RBX: ffff8800a41fb4e8 RCX: ffff8800a41fb450
> > > [13090.416102] RDX: 0000000000000001 RSI: 0000000000000002 RDI: 000000001b340000
> > > [13090.426003] RBP: ffff88012b4c7af8 R08: 000000001b340000 R09: ffff88008ae6f6e0
> > > [13090.435920] R10: ffff880000000000 R11: 0000000000000000 R12: ffff8801156e86f0
> > > [13090.445782] R13: 0000000000000000 R14: ffff8801156e86c0 R15: 0000000000000000
> > > [13090.455627] FS:  0000000000000000(0000) GS:ffff88013fa80000(0063) knlGS:00000000f75ae750
> > > [13090.466451] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> > > [13090.475010] CR2: 0000000000000028 CR3: 0000000115614000 CR4: 00000000000407e0
> > > [13090.484921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > [13090.494802] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > [13090.504649] Process mount (pid: 9658, threadinfo ffff88012b4c6000, task ffff88008d91c4c0)
> > > [13090.515567] Stack:
> > > [13090.520209]  ffff88012b4c7a28 ffffffff81175f65 ffff88012b4c7a88 ffffffff81179c44
> > > [13090.530426]  ffff880100001000 00000000fffffff5 ffffffffa41fb438 ffff8801156e8748
> > > [13090.540694]  00000000000a77ff ffff8800a41fb438 0000000008007800 ffff880122e67800
> > > [13090.551124] Call Trace:
> > > [13090.556238]  [<ffffffff81175f65>] ? brelse+0xe/0x10
> > > [13090.564018]  [<ffffffff81179c44>] ? ext4_mark_iloc_dirty+0x51c/0x581
> > > [13090.573175]  [<ffffffff8119d51c>] ext4_ext_truncate+0xcd/0x179
> > > [13090.581856]  [<ffffffff81132b1c>] ? __inode_wait_for_writeback+0x67/0xa9
> > > [13090.591316]  [<ffffffff81177e74>] ext4_truncate+0x9c/0xdf
> > > [13090.599434]  [<ffffffff8117b721>] ext4_evict_inode+0x1e9/0x2d6
> > > [13090.608273]  [<ffffffff811282e3>] evict+0xa8/0x162
> > > [13090.615846]  [<ffffffff81128588>] iput+0x1b3/0x1bb
> > > [13090.623284]  [<ffffffff8119570d>] ext4_fill_super+0x214b/0x256b
> > > [13090.631785]  [<ffffffff8128f835>] ? vsnprintf+0x1ce/0x421
> > > [13090.639778]  [<ffffffff8113f9b2>] ? set_blocksize+0x36/0x86
> > > [13090.647864]  [<ffffffff811169ae>] mount_bdev+0x14b/0x1ad
> > > [13090.655707]  [<ffffffff811935c2>] ? ext4_calculate_overhead+0x247/0x247
> > > [13090.664876]  [<ffffffff8112ada7>] ? alloc_vfsmnt+0xa6/0x198
> > > [13090.672989]  [<ffffffff81184d5f>] ext4_mount+0x10/0x12
> > > [13090.680564]  [<ffffffff81117390>] mount_fs+0x64/0x150
> > > [13090.687944]  [<ffffffff810e5439>] ? __alloc_percpu+0xb/0xd
> > > [13090.695702]  [<ffffffff8112b156>] vfs_kern_mount+0x64/0xde
> > > [13090.703435]  [<ffffffff8112b544>] do_kern_mount+0x48/0xda
> > > [13090.711023]  [<ffffffff8112ce32>] do_mount+0x6a1/0x704
> > > [13090.718294]  [<ffffffff810e1181>] ? memdup_user+0x38/0x60
> > > [13090.725767]  [<ffffffff810e11df>] ? strndup_user+0x36/0x4c
> > > [13090.733260]  [<ffffffff8114ffaa>] compat_sys_mount+0x208/0x242
> > > [13090.741047]  [<ffffffff814b0b06>] sysenter_dispatch+0x7/0x21
> > > [13090.748612] Code: ff 4c 63 65 b8 4d 6b e4 30 4c 03 65 b0 e9 fd 00 00 00 48 63 55 b8 4c 6b e2 30 4c 03 65 b0 49 83 7c 24 20 00 75 0e 49 8b 44 24 28 <48> 8b 40 28 49 89 44 24 20 49 8b 44 24 18 48 85 c0 75 22 49 8b 
> > > [13090.772841] RIP  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > > [13090.781438]  RSP <ffff88012b4c7a18>
> > > [13090.786758] CR2: 0000000000000028
> > > [13090.804674] ---[ end trace 880c73500bb7f09f ]---
> > > [13090.810808] Kernel panic - not syncing: Fatal exception
> > > [13090.817346] panic occurred, switching back to text console
> > > [13090.824556] Rebooting in 20 seconds..
> > > [13110.758740] ACPI MEMORY or I/O RESET_REG.
> > > 
> > 
> 
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems ....
>                                       .... what McDonalds is to gourmet cooking
> Home page: http://marc.merlins.org/

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ext4 crash with 3.5.2 in ext4_ext_remove_space

[Lukáš Czerner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 8003 bytes --]

On Fri, 7 Sep 2012, Marc MERLIN wrote:

> Date: Fri, 7 Sep 2012 08:19:42 -0700
> From: Marc MERLIN <marc@merlins.org>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: linux-ext4@vger.kernel.org
> Subject: Re: ext4 crash with 3.5.2 in ext4_ext_remove_space
> 
> On Wed, Sep 05, 2012 at 09:24:26PM -0700, Marc MERLIN wrote:
> > On Wed, Sep 05, 2012 at 01:50:54PM -0400, Lukáš Czerner wrote:
> > > Hi,
> > > 
> > > I believe that this has been fixed with v3.6-rc1-5-g89a4e48 and it
> > > was marked for stable release as well.
> > 
> > If that helps, it was indeed a single orphaned inode. After clearing it, 
> > I was able to mount the partition without problems.
> > 
> > gargamel:~# e2fsck -y /dev/mapper/dshelf2-space
> > e2fsck 1.42.5 (29-Jul-2012)
> > /dev/mapper/dshelf2-space: recovering journal
> > Clearing orphaned inode 92668757 (uid=1002, gid=8, mode=0100660, size=6574695342)
> > /dev/mapper/dshelf2-space: clean, 16987882/114098176 files, 426716110/456392704 blocks
> 
> Would you happen to have a link to the patch, I had this crash again, I'd
> like to check if it's in 3.5.3 or apply it myself to stop further crashes.
> 
> Thanks,
> Marc

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=89a4e48f8479f8145eca9698f39fe188c982212f

-Lukas


>  
> > Cheers,
> > Marc
> > 
> > > -Lukas
> > > 
> > > On Wed, 5 Sep 2012, Marc MERLIN wrote:
> > > 
> > > > Date: Wed, 5 Sep 2012 09:52:10 -0700
> > > > From: Marc MERLIN <marc@merlins.org>
> > > > To: linux-ext4@vger.kernel.org
> > > > Subject: ext4 crash with 3.5.2 in ext4_ext_remove_space
> > > > 
> > > > I get a crash when mounting a filesystem.
> > > > I'm making an image now with e2image -r before I run e2fsck on it.
> > > > 
> > > > Is there anything else you'd like me to do?
> > > > 
> > > > [13090.175424] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> > > > [13090.184897] IP: [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > > > [13090.192927] PGD 1120d7067 PUD 1123ac067 PMD 0 
> > > > [13090.198469] Oops: 0000 [#1] PREEMPT SMP 
> > > > [13090.203508] CPU 1 
> > > > [13090.205368] Modules linked in:[13090.209508]  ppdev lp tun autofs4 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx sata_mv kl5kusb105 ftdi_sio keyspan nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_state xt_tcpudp xt_LOG iptable_mangle iptable_filter deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 lrw serpent_generic xts gf128mul cast5 des_generic xcbc rmd160 sha512_generic crypto_null af_key xfrm_algo blowfish_generic blowfish_x86_64 blowfish_common dm_crypt dm_mirror dm_region_hash dm_log aes_x86_64 fuse lm85 hwmon_vid dm_snapshot dm_mod iptable_nat ip_tables nf_conntrack_ftp ipt_MASQUERADE nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 x_tables nf_connt
 rack sg st snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek rc_ati_x10 ati_remote rc_core pl2303 usbserial i915 snd_hda_intel snd_cmipci snd_hda_codec gameport drm_kms_hel!
 per dr!
> > >  m !
> > > >  snd_opl3_lib snd_mpu401_uart eeepc_wmi asus_wmi
> > > >  i2c_algo_bit[13090.315877]  sparse_keymap rfkill snd_hwdep snd_seq_midi acpi_cpufreq snd_seq_midi_event mperf kvm_intel kvm processor snd_seq snd_pcm pci_hotplug ehci_hcd wmi parport_pc xhci_hcd microcode button video sata_sil24 parport snd_rawmidi snd_timer usbcore crc32c_intel ghash_clmulni_intel i2c_i801 snd_seq_device cryptd evdev snd lpc_ich mei i2c_core pcspkr snd_page_alloc thermal_sys usb_common soundcore coretemp r8169 mii tpm_tis tpm tpm_bios [last unloaded: kl5kusb105]
> > > > 
> > > > [13090.370146] Pid: 9658, comm: mount Not tainted 3.5.2-amd64-preempt-noide-20120903 #1 System manufacturer System Product Name/P8H67-M PRO
> > > > [13090.387559] RIP: 0010:[<ffffffff8119b92f>]  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > > > [13090.398254] RSP: 0018:ffff88012b4c7a18  EFLAGS: 00010246
> > > > [13090.406241] RAX: 0000000000000000 RBX: ffff8800a41fb4e8 RCX: ffff8800a41fb450
> > > > [13090.416102] RDX: 0000000000000001 RSI: 0000000000000002 RDI: 000000001b340000
> > > > [13090.426003] RBP: ffff88012b4c7af8 R08: 000000001b340000 R09: ffff88008ae6f6e0
> > > > [13090.435920] R10: ffff880000000000 R11: 0000000000000000 R12: ffff8801156e86f0
> > > > [13090.445782] R13: 0000000000000000 R14: ffff8801156e86c0 R15: 0000000000000000
> > > > [13090.455627] FS:  0000000000000000(0000) GS:ffff88013fa80000(0063) knlGS:00000000f75ae750
> > > > [13090.466451] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> > > > [13090.475010] CR2: 0000000000000028 CR3: 0000000115614000 CR4: 00000000000407e0
> > > > [13090.484921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > [13090.494802] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > [13090.504649] Process mount (pid: 9658, threadinfo ffff88012b4c6000, task ffff88008d91c4c0)
> > > > [13090.515567] Stack:
> > > > [13090.520209]  ffff88012b4c7a28 ffffffff81175f65 ffff88012b4c7a88 ffffffff81179c44
> > > > [13090.530426]  ffff880100001000 00000000fffffff5 ffffffffa41fb438 ffff8801156e8748
> > > > [13090.540694]  00000000000a77ff ffff8800a41fb438 0000000008007800 ffff880122e67800
> > > > [13090.551124] Call Trace:
> > > > [13090.556238]  [<ffffffff81175f65>] ? brelse+0xe/0x10
> > > > [13090.564018]  [<ffffffff81179c44>] ? ext4_mark_iloc_dirty+0x51c/0x581
> > > > [13090.573175]  [<ffffffff8119d51c>] ext4_ext_truncate+0xcd/0x179
> > > > [13090.581856]  [<ffffffff81132b1c>] ? __inode_wait_for_writeback+0x67/0xa9
> > > > [13090.591316]  [<ffffffff81177e74>] ext4_truncate+0x9c/0xdf
> > > > [13090.599434]  [<ffffffff8117b721>] ext4_evict_inode+0x1e9/0x2d6
> > > > [13090.608273]  [<ffffffff811282e3>] evict+0xa8/0x162
> > > > [13090.615846]  [<ffffffff81128588>] iput+0x1b3/0x1bb
> > > > [13090.623284]  [<ffffffff8119570d>] ext4_fill_super+0x214b/0x256b
> > > > [13090.631785]  [<ffffffff8128f835>] ? vsnprintf+0x1ce/0x421
> > > > [13090.639778]  [<ffffffff8113f9b2>] ? set_blocksize+0x36/0x86
> > > > [13090.647864]  [<ffffffff811169ae>] mount_bdev+0x14b/0x1ad
> > > > [13090.655707]  [<ffffffff811935c2>] ? ext4_calculate_overhead+0x247/0x247
> > > > [13090.664876]  [<ffffffff8112ada7>] ? alloc_vfsmnt+0xa6/0x198
> > > > [13090.672989]  [<ffffffff81184d5f>] ext4_mount+0x10/0x12
> > > > [13090.680564]  [<ffffffff81117390>] mount_fs+0x64/0x150
> > > > [13090.687944]  [<ffffffff810e5439>] ? __alloc_percpu+0xb/0xd
> > > > [13090.695702]  [<ffffffff8112b156>] vfs_kern_mount+0x64/0xde
> > > > [13090.703435]  [<ffffffff8112b544>] do_kern_mount+0x48/0xda
> > > > [13090.711023]  [<ffffffff8112ce32>] do_mount+0x6a1/0x704
> > > > [13090.718294]  [<ffffffff810e1181>] ? memdup_user+0x38/0x60
> > > > [13090.725767]  [<ffffffff810e11df>] ? strndup_user+0x36/0x4c
> > > > [13090.733260]  [<ffffffff8114ffaa>] compat_sys_mount+0x208/0x242
> > > > [13090.741047]  [<ffffffff814b0b06>] sysenter_dispatch+0x7/0x21
> > > > [13090.748612] Code: ff 4c 63 65 b8 4d 6b e4 30 4c 03 65 b0 e9 fd 00 00 00 48 63 55 b8 4c 6b e2 30 4c 03 65 b0 49 83 7c 24 20 00 75 0e 49 8b 44 24 28 <48> 8b 40 28 49 89 44 24 20 49 8b 44 24 18 48 85 c0 75 22 49 8b 
> > > > [13090.772841] RIP  [<ffffffff8119b92f>] ext4_ext_remove_space+0x83d/0xb51
> > > > [13090.781438]  RSP <ffff88012b4c7a18>
> > > > [13090.786758] CR2: 0000000000000028
> > > > [13090.804674] ---[ end trace 880c73500bb7f09f ]---
> > > > [13090.810808] Kernel panic - not syncing: Fatal exception
> > > > [13090.817346] panic occurred, switching back to text console
> > > > [13090.824556] Rebooting in 20 seconds..
> > > > [13110.758740] ACPI MEMORY or I/O RESET_REG.
> > > > 
> > > 
> > 
> > -- 
> > "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> > Microsoft is to operating systems ....
> >                                       .... what McDonalds is to gourmet cooking
> > Home page: http://marc.merlins.org/
> 
> 

Re: ext4 crash with 3.5.2 in ext4_ext_remove_space

[Marc MERLIN]

On Fri, Sep 07, 2012 at 11:39:53AM -0400, Lukáš Czerner wrote:
> > Would you happen to have a link to the patch, I had this crash again, I'd
> > like to check if it's in 3.5.3 or apply it myself to stop further crashes.
> > 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=89a4e48f8479f8145eca9698f39fe188c982212f

Cool, I just confirmed it's in 3.5.3 already.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html