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

Powered by Openwall GNU/*/Linux Powered by OpenVZ