From: Max Stirling <vicky.irobot@gmail.com>
To: Sergei Sharonov <sergei.sharonov@halliburton.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: mtdblock mount issue
Date: Fri, 08 Feb 2008 16:01:55 +0530 [thread overview]
Message-ID: <47AC2F9B.60009@gmail.com> (raw)
In-Reply-To: <loom.20080207T155530-907@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
Sergei Sharonov wrote:
>> I am trying to mount a cramfs partition from flash.
>>
>
> A word of warning. CRAMFS is broken in kernels < 2.6.18. As far as I can tell,
> under heavy load (e.g. reading multiple files in parallel that are not cached)
> it may fail with decompression errors. I think the issue is not exactly with
> cramfs but with some interaction with page cache. Backporting just cramfs files
> to 2.6.15 did not help. If you have drop_caches interface (kernel > 2.6.16 or
> just backport it) it is easy to reproduce. Otherwise it happens _very_
> infrequently because most of the time files are already cached. However the
> consequences are severe - corrupted executables, etc.
> Here is a script to reproduce the problem:
>
> ===============================================
> # Copy large file from cramfs to tmpfs
> cp /bin/smbd /tmp/
>
> # First concurrent access to files/directories
> while [ 1 ]; do cat /bin/* > /dev/null; done &
>
> # Second concurrent access to test file and cache flush
> for((i=0;i<99999;i++)) do echo -n "cycle=$i ";
> cmp /bin/smbd /tmp/smbd ;
> echo 3 > /proc/sys/vm/drop_caches ;
> done
> ===============================================
>
> Note that /bin is in cramfs. smbd can be any large file.
> I've also seen statements that drop_caches interface is not 100% reliable.
> Nevertheless I have experienced decompression errors even without forcing
> cache purge.
> Above script has caused failures on PowerPC/2.6.16 and ARM9/2.6.15.
> 2.6.18 and 2.6.23 seem ok.
>
> Regards,
>
> Sergei
>
> P.S. Yes, cramfs has little to do with MTD but since ppl here use it with flash
> I felt it was a good idea to post this warning.
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
thanks for the info. I think I will check out squashfs then.
But before that I wanted to fix the issue that I am seeing. There might
be something wrong in my implementation?
BTW I thought this was the right mailing list, since I am trying to
mount cramfs image using MTD. Can you point me to the right mailing list?
[-- Attachment #2: vicky_irobot.vcf --]
[-- Type: text/x-vcard, Size: 48 bytes --]
begin:vcard
fn:M S
n:S;M
version:2.1
end:vcard
prev parent reply other threads:[~2008-02-08 10:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-04 14:19 mtdblock mount issue Max Stirling
2008-02-06 16:20 ` Adams Richard-W36112
2008-02-07 6:16 ` Max Stirling
2008-02-07 16:28 ` Sergei Sharonov
2008-02-08 10:31 ` Max Stirling [this message]
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=47AC2F9B.60009@gmail.com \
--to=vicky.irobot@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sergei.sharonov@halliburton.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.