I used Samsung OneNAND flash memory, and MTD was not used at all.
I just analyzed block layer using blktrace, and found out that there
are a lot of consecutive requests with 1k size.
And BTW: elevator almost did not merge consecutive requests. That's
interesting issue for me.
Thank you for pointing me that fact. So I guess, that block layer (not
MTD) should be more carefully analyzed
and I should find out why elevator does not work, like it should.
On Tue, Feb 12, 2008 at 12:31 PM, Phillip Lougher
> Lelik Bolik wrote:
> > Thanks Phillip for the reply.
> > But I didn't mean compression block size, I meant block layer block size.
> > This size is used to request data from block layer.
> > To make my question more clear, I attached patch, which I used for tests.
> > - msblk->devblksize = sb_min_blocksize(s, BLOCK_SIZE);
> > +// msblk->devblksize = sb_min_blocksize(s, BLOCK_SIZE);
> For the benefit of other readers this sets the underlying buffer cache
> I/O to be the minimum of 1K (BLOCK_SIZE) or the smallest block size
> supported by the block device (between 1K and 4K).
> Your question now makes more sense.
> As you may be aware Squashfs filesystem blocks are not aligned on sector
> boundaries but on byte boundaries to maximise compresssion. What this
> means is that when reading a Squashfs block in units of the above buffer
> cache size it will invariably involve a partial read of the first buffer
> cache block and a partial read of the last buffer cache block. The
> smaller the buffer cache I/O block the less wasted I/O is performed.
> For instance a Squashfs block overlapping 60 bytes into the last buffer
> cache block @ 1K I/O size results in less wasted I/O than @ 4K I/O size.
> Squashfs queues the buffer I/O requests in one operation, and assuming a
> correctly working elevator algorithm, consecutive 1K buffer cache reads
> should perform identically to consecutive 4K buffer cache reads. This
> is especially true with 'modern' intelligent disks and I/O controllers
> with large readahead buffers which optimise for sequential access.
> So given my previous comment that smaller buffer cache block size
> results in less I/O performed by Squashfs, I'm therefore surprised you
> find a 7% boot time speed up moving from a 1K block size to a 4K block
> size. What block device did you do your tests on? From you question
> I'm assuming it is a flash device (is it NOR or NAND?) via the MTD block
> I can only assume your flash driver (or the MTD stack) has a high access
> latency per block access which is incurred even when block accesses are
> consecutive. Incidentally elevator algorithms have little effect on
> flash access performance because seek time between blocks on flash is
> I will do some tests on other block devices to check their behaviour
> when I have time. Thanks for bringing this to my attention.
> > On Tue, Feb 12, 2008 at 9:54 AM, Phillip Lougher
> > <phillip@...> wrote:
> >> Lelik Bolik wrote:
> >> > Dear all.
> >> > By default Linux kernel uses 1k FS block size.
> >> > AFAIK, Squash FS is mainly used on embededded system with 4k page size
> >> > and flash memory. And almost all VFS operation are made on whole
> >> > pages.
> >> > Increasing FS block size from 1k to 4k could speed up read accesses
> >> > and reduce elevator overhead. It should reduce system boot-up time.
> >> > I've made several tests and they show up to 7% booting time reduction.
> >> > Could You explain, why 1k was chosen as a default FS block size?
> >> >
> >> This shows some confusion.
> >> Linux I/O is conceptually split into two layers the block cache and the
> >> page cache. Buffers in the block cache are of the underlying block
> >> device's sector size which is normally 512 bytes. Page cache buffers
> >> are normally 4K (the page size).
> >> A filesystem is free to use any block size, which doesn't have to be
> >> either the underlying block device sector size or the page size.
> >> However, most often Linux filesystems have 4K block sizes matching the
> >> page size.
> >> Irrespective of the filesystem block size and the sector size, Linux
> >> (the VFS layer) performs I/O on the filesystem in page size units or 4K.
> >> For a given 4K I/O request it is the responsibility of the filesystem
> >> to map that to one of its (possibly different size) blocks, which in
> >> turn it maps down to a series of sector size I/O requests to the
> >> underlying block device.
> >> Prior to version 2.0 Squashfs used 32K blocks, which meant for a given
> >> 4K VFS request it read 32K of data, and pushed the remaining 28K into
> >> the page cache itself. Squashfs from 2.0 to 3.2 used 64K blocks, and
> >> the latest 3.3 version uses by default 128K blocks.
> >> So to directly answer your question, Squashfs doesn't use 1K blocks, it
> >> already uses 128K blocks.
> >> Phillip
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________
> > Squashfs-devel mailing list
> > Squashfs-devel@... > > https://lists.sourceforge.net/lists/listinfo/squashfs-devel > >