linux-kernel - Re: ext4_da_release_space:1333: ext4_da_release_space: ino 12, to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130717213850.GA5025@quack.suse.cz>
Date:	Wed, 17 Jul 2013 23:38:50 +0200
From:	Jan Kara <jack@...e.cz>
To:	Dave Jones <davej@...hat.com>
Cc:	Jan Kara <jack@...e.cz>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-ext4@...r.kernel.org
Subject: Re: ext4_da_release_space:1333: ext4_da_release_space: ino 12,
 to_free 1 with only 0 reserved data  blocks

On Wed 17-07-13 10:52:18, Dave Jones wrote:
> On Wed, Jul 17, 2013 at 02:53:22PM +0200, Jan Kara wrote:
>  > On Tue 16-07-13 16:25:33, Dave Jones wrote:
>  > > I've seen this happen a few times this week..
>  >   Thanks for report! Was this when fuzzing or just normal desktop load?
>  > What is inode with inode number 12 on your filesystem sdb1? What IO happens
>  > to it? Apparently some delalloc accounting went wrong somewhere and it's
>  > searching for a needle in a haystack unless we have more details...
> 
> It was running this.. https://github.com/kernelslacker/io-tests/blob/master/setup.sh
> in a loop. After about 6 hours, that fell out.  It made it all the way through
> every test a few times, which is odd, as the test should be fairly deterministic.
> Ah, I wasn't capturing the fsx seed. I'll do that on the next run.
  So inode 12 was likely the file used by fsx. OK. Looking at the script
link, fsx is run as:
  /usr/local/bin/fsx -N 250000 -S0 foo &
so the seed is always 0. So it is a deterministic test and there must be
some race with writeback or something that is rarely triggered. Drat.

Umm, looking at the filesystems this tests, ext4 with 1 KB blocksize is
likely the config which hits this (the accounting is more complex there) so
it might be interesting to concentrace on this one.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/