public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: NamJae Jeon <linkinjeon@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Squashfs updates for 3.2
Date: Fri, 04 Nov 2011 16:25:31 +0000	[thread overview]
Message-ID: <4EB411FB.8050803@lougher.demon.co.uk> (raw)
In-Reply-To: <CAKYAXd87eNQqDs2Ks5pFkA8dxsb49Ub2UmmWfsQVC8n6F3sfKA@mail.gmail.com>

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

  reply	other threads:[~2011-11-04 16:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04 14:03 [GIT PULL] Squashfs updates for 3.2 Phillip Lougher
2011-11-04 14:38 ` NamJae Jeon
2011-11-04 16:25   ` Phillip Lougher [this message]
2011-11-04 16:34     ` Phillip Lougher
2011-11-04 23:16       ` NamJae Jeon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB411FB.8050803@lougher.demon.co.uk \
    --to=phillip@lougher.demon.co.uk \
    --cc=linkinjeon@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox