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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 23 Mar 2011 11:28:14 +0100 (CET)
From:	Lukas Czerner <lczerner@...hat.com>
To:	"Ted Ts'o" <tytso@....edu>
cc:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH, RFC 01/12] ext4: read-only support for bigalloc file
 systems

On Tue, 22 Mar 2011, Ted Ts'o wrote:

> On Mon, Mar 21, 2011 at 08:35:20PM +0100, Lukas Czerner wrote:
> > 
> > Maybe this is a bit nitpicky, but should not this be rather done in
> > separate commit as it has nothing to do with bigalloc ?
> 
> Perhaps.  The reason why I had it was because I wanted to see the
> blocks per group information when I was testing a read-only bigalloc
> mount.  I'll grant this is tenuous; I suppose I could separate out
> these two patch hunks into a separate patch, but I didn't think it was
> really worth it.
> 
> > 
> > I wonder if we should continue at this point, because something
> > definitely went wrong as it has not biballoc feature but yet
> > s_log_cluster_size does not match s_log_block_size which means
> > definitely corruption or an error somewhere.
> 
> I considered this, but I was just paranoid because I didn't want to
> change anything in the !bigalloc case.  There was one or two users who
> reported that somehow the second 512 byte sector was containing
> garbage, and nothing had cared in the past, but when we first broke
> into the second 512 bytes of the superblock we did have some
> complaints, so that's why I decided to err on the side of
> conservatism.

Right, I can see your point. So maybe we should add this check to e2fsck
to set the s_log_cluster_size properly if bigalloc is not set.

> 
> 						- Ted
> --
> 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
> 

-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