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
| ||
|
Date: Sat, 18 Apr 2009 19:07:34 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Matti Aarnio <matti.aarnio@...iler.org> CC: Jesper Juhl <jj@...osbits.net>, Prakash Punnoor <prakash@...noor.de>, Michael Tokarev <mjt@....msk.ru>, linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org, neilb@...e.de Subject: Re: Proposal: make RAID6 code optional Matti Aarnio wrote: > > I did quick "sum of symbol sizes" lookup of the raid.ko, and got > it like this: > > nm -t d -n -S /lib/modules/2.6.27.21-170.2.56.fc10.x86_64/kernel/drivers/md/raid456.ko | grep raid4|awk '{print $2}'|sed -e 's/^0*//g'|awk '{sum+=$1}END{print sum}' > ... > > raid4: 152 > raid5: 7165 > raid6: 75558 > > Entire 64kB of that raid6 is single pre-initialized r/o datablock: raid6_gfmul > > So yes, having RAID6 personality as separate module would be appropriate for > systems that are only interested in RAID4 or RAID5. Separating the RAID4 > personality wastes space, separating RAID5 ... barely 2 of 4k memory pages. > RAID 4 is really just another layout scheme for RAID 5. But yes, moving RAID 6 to a separate module makes sense. The amount of RAID 5 code not used by RAID 6 is fairly trivial, so the right way to do this is to have the raid6 module depend on the raid5 module. There used to be a raid6 module which was forked from raid5, with a lot of duplicate code. That really made really no sense. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/
Powered by blists - more mailing lists