[GIT PULL] Squashfs updates for 3.2

[GIT PULL] Squashfs updates for 3.2

[Phillip Lougher]

Hi Linus,

Please consider pulling the following minor Squashfs update.

Thanks

Phillip


The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:

   Linux 3.1 (2011-10-24 09:10:05 +0200)

are available in the git repository at:
   git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-next.git master

Phillip Lougher (1):
       Squashfs: Add an option to set dev block size to 4K

  fs/squashfs/Kconfig       |   22 ++++++++++++++++++++++
  fs/squashfs/squashfs_fs.h |    7 +++++++
  fs/squashfs/super.c       |    2 +-
  3 files changed, 30 insertions(+), 1 deletions(-)

Re: [GIT PULL] Squashfs updates for 3.2

[NamJae Jeon]

2011/11/4 Phillip Lougher <phillip@lougher.demon.co.uk>:
> Hi Linus,
>
> Please consider pulling the following minor Squashfs update.
>
> Thanks
>
> Phillip
>
>
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
>  Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
>  git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-next.git master
>
> Phillip Lougher (1):
>      Squashfs: Add an option to set dev block size to 4K
>
>  fs/squashfs/Kconfig       |   22 ++++++++++++++++++++++
>  fs/squashfs/squashfs_fs.h |    7 +++++++
>  fs/squashfs/super.c       |    2 +-
>  3 files changed, 30 insertions(+), 1 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
Hi. Phillip.

I already posted this patch before ([PATCH] squashfs : devblksize set
to 4KB intead of BLOCK_SIZE(1KB).).
It is similar with my patch except option.
Have you ever seen this patch ? I didn't response about this patch from you.

Thanks.

Re: [GIT PULL] Squashfs updates for 3.2

[Phillip Lougher]

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.

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.

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

Phillip

Re: [GIT PULL] Squashfs updates for 3.2

[Phillip Lougher]

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

Re: [GIT PULL] Squashfs updates for 3.2

[NamJae Jeon]

2011/11/5 Phillip Lougher <phillip@lougher.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
>>
>
>