| 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, 5 Nov 2011 08:16:24 +0900 From: NamJae Jeon <linkinjeon@...il.com> To: Phillip Lougher <phillip@...gher.demon.co.uk> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Linux Kernel Development <linux-kernel@...r.kernel.org> Subject: Re: [GIT PULL] Squashfs updates for 3.2 2011/11/5 Phillip Lougher <phillip@...gher.demon.co.uk>: > Phillip Lougher wrote: >> >> NamJae Jeon wrote: >> >>> >>> I already posted this patch before ([PATCH] squashfs : devblksize set >>> to 4KB intead of BLOCK_SIZE(1KB).). >> >> No you didn't. You posted a patch that simply unconditionally changed >> the block size from 1K -> 4K. >> >> https://lkml.org/lkml/2011/9/18/66 >> >> This is an unacceptable change, Squashfs is used on many devices not only >> NAND, and the default value of 1K is optimal for these other devices, and >> should not be changed. I suggested this change two time. RFC and a Patch. I didn't reply from you although you read my post. you have usually ignored a patch without the reply or the opinion whenever you get a patch. and contribute a patch with your name after changing a little more. >> >> Second, if you are going to change long-term existing behaviour you should >> always allow users to "buy-in" to the change, rather than surprising them >> with new unexpected behaviour. >> >>> It is similar with my patch except option. >> >> The option *is* the patch. You may add config option on my patch. I think that 1k-4k is core. if you think option is core of patch, no more to say. I also am considering to make config option or mount option 1,4K dev blk size before. So I am waiting after I send RFC mail to know your opinion first. >> >>> Have you ever seen this patch ? I didn't response about this patch from >>> you. >> >> Since 2008 (and probably before) I have had reports that a 1K block size >> was >> causing performance issues on NAND >> >> http://old.nabble.com/Default-FS-block-size-td15423970.html >> >> However, I chose to do nothing at that time because the results were >> inconclusive. >> >> The impetus for moving to a 1K block on NAND was due to the development >> of the UBIBLK driver for NAND earlier this year >> >> http://lists.infradead.org/pipermail/linux-mtd/2011-June/036595.html >> >> where the 1K dev block behaviour of Squashfs was discovered to be the >> reason (in the early V1 driver referenced above) why Squashfs filesystems >> worked, but ext2/3 and vfat filesystems did not. >> >> Your patch was merely the 3rd or 4th unacceptable patch I have >> received changing the block size unconditionally. >> >> The month before your patch I received this truly horrible patch, which >> though it is extremely long, does nothing more than change the max dev >> block size to 4K. I dropped that patch too. >> > > Missing link > > https://lkml.org/lkml/2011/8/15/350 > > oh and the patch was truly horrible because it was > broken, they added a new set of I/O access routines > for the LZO decompressor, but didn't bother with > any of the others (compile error if you were so > audacious as to want to use GZIP, or XZ). > > Way to go. > >> Phillip >> > > -- 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