* CRAMFS or SQUASHFS
@ 2003-06-03 23:04 Robin Gilks
2003-06-03 23:39 ` David Updegraff
2003-06-04 0:31 ` Eugene Surovegin
0 siblings, 2 replies; 3+ messages in thread
From: Robin Gilks @ 2003-06-03 23:04 UTC (permalink / raw)
To: linuxppc embedded
Greetings
I've been trying to determine the best Flash based *_read-only_* compressed
filesystem for an embedded system.
I can find nothing about CRAMFS - not even what it stands for - is it CRAM as in
squeeze it all in or Compressed RAM meaning it uses loads of RAM to expand into.
Just a hint in the right direction here would help!!
For SQUASHFS, I'm unsure as to how mature it is and what its memory overhead is
since its using zlib - would the discussions about sharing zlib workspace be
relevant here as well?
Does anyone have a horror story particular to either of these technologies?
Many thanks...
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CRAMFS or SQUASHFS
2003-06-03 23:04 CRAMFS or SQUASHFS Robin Gilks
@ 2003-06-03 23:39 ` David Updegraff
2003-06-04 0:31 ` Eugene Surovegin
1 sibling, 0 replies; 3+ messages in thread
From: David Updegraff @ 2003-06-03 23:39 UTC (permalink / raw)
To: Robin Gilks; +Cc: linuxppc embedded
We ended up with squashfs since it gave better compression, better runtime
performance, and -- most importantly for us -- the 'mksquashfs' suite is
easy to compile up on non-Linux unixes, and it handles endiannes issues.
>
>
> Greetings
>
> I've been trying to determine the best Flash based *_read-only_* compressed
> filesystem for an embedded system.
>
> I can find nothing about CRAMFS - not even what it stands for - is it CRAM as in
> squeeze it all in or Compressed RAM meaning it uses loads of RAM to expand into.
> Just a hint in the right direction here would help!!
>
> For SQUASHFS, I'm unsure as to how mature it is and what its memory overhead is
> since its using zlib - would the discussions about sharing zlib workspace be
> relevant here as well?
>
> Does anyone have a horror story particular to either of these technologies?
>
> Many thanks...
>
> --
> Robin Gilks
> Senior Design Engineer Phone: (+64)(3) 357 1569
> Tait Electronics Fax : (+64)(3) 359 4632
> PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
> New Zealand
>
>
>
--
Dave Updegraff, Cray Inc. / dave@cray.com / 218-525-1154
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CRAMFS or SQUASHFS
2003-06-03 23:04 CRAMFS or SQUASHFS Robin Gilks
2003-06-03 23:39 ` David Updegraff
@ 2003-06-04 0:31 ` Eugene Surovegin
1 sibling, 0 replies; 3+ messages in thread
From: Eugene Surovegin @ 2003-06-04 0:31 UTC (permalink / raw)
To: Robin Gilks; +Cc: linuxppc embedded
At 04:04 PM 6/3/2003, Robin Gilks wrote:
>I've been trying to determine the best Flash based *_read-only_* compressed
>filesystem for an embedded system.
>
>I can find nothing about CRAMFS - not even what it stands for - is it CRAM
>as in
>squeeze it all in or Compressed RAM meaning it uses loads of RAM to expand
>into.
>Just a hint in the right direction here would help!!
Did you read Documentation/filesystems/cramfs ??????
We use cramfs in one of our embedded products along with read-only MTD
block device.
No problems so far :)
BTW, patch exists that solves endianess problems in mkcramfs.
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-06-04 0:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-03 23:04 CRAMFS or SQUASHFS Robin Gilks
2003-06-03 23:39 ` David Updegraff
2003-06-04 0:31 ` Eugene Surovegin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).