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]
Date:	Thu, 14 Mar 2013 08:56:55 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Jan Kara <jack@...e.cz>
cc:	Dmitry Monakhov <dmonakhov@...nvz.org>, linux-ext4@...r.kernel.org,
	Ted Tso <tytso@....edu>
Subject: Re: Unwritten extent zeroing beyond i_size

On Wed, 13 Mar 2013, Jan Kara wrote:

> Date: Wed, 13 Mar 2013 10:56:40 +0100
> From: Jan Kara <jack@...e.cz>
> To: Dmitry Monakhov <dmonakhov@...nvz.org>
> Cc: linux-ext4@...r.kernel.org, Ted Tso <tytso@....edu>
> Subject: Unwritten extent zeroing beyond i_size
> 
>   Hello Dmitry,
> 
>   I'm tracking down failure in xfstests test 274 (fallocate + ENOSPC
> testing). The problem I found (and that's really unrelated to the question
> I want to ask) is that if write beyond i_size fails, we truncate the file
> to i_size to remove any blocks that may have been allocated under the page
> by the write before it failed (think of blocksize < pagesize config).
> 
> Now in this test the write fails because it needs to split unwritten extent
> and there's no space for that and zeroing out is impossible because we are
> beyond i_size. And here comes my question: You disallowed zeroing of
> extents beyond i_size because fsck complains about those. Won't it be
> better to just add inode flag saying "this inode has blocks preallocated
> beyond i_size" and make fsck not complain about such blocks? IMHO that
> would catch 99% of corruptions as well and would let us solve the problem
> with ENOSPC on writes to preallocated space (plus it would simplify the
> kernel code).
> 
> 								Honza

Unfortunately this will not solve the real issue that writing into
preallocated space should _not_ fail at all, because it is
preallocated.

The problem right now is that we simply do not have block to
allocate metadata, and there is no way for us to reserve metadata
blocks in advance as we might try to do in delalloc.

I've proposed the solution for this in the recent email with subject
"Metadata reservation for unwritten extent conversion". Basically
the idea is to have reserved pool of blocks which could be used for
exactly this (and other) cases. Note that xfs actually have the same
thing for exactly the same reasons.

I'll send the patch implementing this soon.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ