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] [day] [month] [year] [list]
Message-ID: <20080110082223.GF3351@webber.adilger.int>
Date:	Thu, 10 Jan 2008 01:22:23 -0700
From:	Andreas Dilger <adilger@....com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	cmm@...ibm.com, tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: Use superblock s_raid_stripe_width as stripe size
	during block allocation.

On Jan 10, 2008  09:58 +0530, Aneesh Kumar K.V wrote:
> > d) if s_stripe is still > s_blocks_per_group try s_raid_stride
> > e) if s_stripe is still > s_blocks_per_group use 0
> 
> But i guess mke2fs and tune2fs should validate the value of
> s_raid_stripe_width and s_raid_stride. Both of them should be less that
> blocks per group. Should I add extra check in the kernel for them ?

It's true that mke2fs and tune2fs should validate this, but it is also
possible to become corrupted, and e2fsck doesn't fix it yet nor can it
make a good estimate of the right value.

> > > +	if (!sbi->s_stripe ||
> > > +			sbi->s_stripe >= sbi->s_blocks_per_group) {
> > 
> 
> So what do you think should it be > or >=. Looking at the mballoc I
> guess it should work with stripe size equal to blocks per group. I am
> not sure how efficient the allocation would be though.

I think if s_stripe == s_blocks_per_group that is fine...  For 1kB block
filesystem that is only 8MB in size.

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@...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