In message [off-list ref] you wrote:
with this configuration, it's obviously not possible to update files
or directories in the bootable image individually -- it's just one big
zImage.inited image.
What makes you think that this is not possible? If there is (for
example) a writable JFFS2 partition available, you can use this for
an overlay filesystem to store the updates.
See for example the "mini_fo" overlay filesystem on our FTP server
and the paper about it:
http://www.denx.de/PDF/Diplomarbeit-MK-1.0-net.pdf
but is it feasible to redefine the layout of that flash chip and
take, say, 4M of it and create a JFFS2 filesystem, then put the root
filesystem in there uncompressed? (assuming, of course, that the
Standard JFFS2 code will always compress.
is this possible? anyone done it this way, and can tell me what
pitfalls i have to watch for? thanks.
This is a pretty standard setup. Although I don't really recommend to
use JFFS2 for root filesystem (for example, because with a big root
filesystem the boot time may deteriorate). Instead, we usually split
the stuff in a read-only partition (for example cramfs), a volatile
part (tmpfs), and a persistent storage partition (JFFS2).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Generally speaking, there are other ways to accomplish whatever it is
that you think you need ... - Doug Gwyn
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, 2004-06-28 at 09:09 +0200, Wolfgang Denk wrote:
quoted
is this possible? anyone done it this way, and can tell me what
pitfalls i have to watch for? thanks.
This is a pretty standard setup. Although I don't really recommend to
use JFFS2 for root filesystem (for example, because with a big root
filesystem the boot time may deteriorate). Instead, we usually split
the stuff in a read-only partition (for example cramfs), a volatile
part (tmpfs), and a persistent storage partition (JFFS2).
I think it should be OK when it's 4MiB in size. Mount time was far more
of a problem in JFFS2 many years ago when people were using the 2.4
kernel. It's a lot faster in 2.6.
There's people looking at making it even faster now, too.
--
dwmw2
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
(sorry, i realize that this isn't directly related to PPC issues.)
as a first followup question, now that i've just created a 4M
partition on an 8M flash chip, and formatted it as JFFS2, if i put a
copy of the root FS on that filesystem, i can of course boot and use
that as my root filesystem. but, at the moment, since i'm booting
with what is essentially a zImage.initrd, the kernel is first loaded,
and then the uncompressed root filesystem is copied into RAM of
course.
i suspect that leaving my root filesystem in flash would cause
noticeable performance problems (even if i managed to structure it so
that it could be read-only). how hard would it be to automatically
have that root FS copied from JFFS2 to RAM and mounted from there?
can that be done as a kernel option i haven't seen? or do i have to
do that manually, involving something like "pivot_root"? or is it
worth the trouble?
On Mon, 28 Jun 2004, Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
with this configuration, it's obviously not possible to update files
or directories in the bootable image individually -- it's just one big
zImage.initrd image.
What makes you think that this is not possible? If there is (for
example) a writable JFFS2 partition available, you can use this for
an overlay filesystem to store the updates.
See for example the "mini_fo" overlay filesystem on our FTP server
and the paper about it:
http://www.denx.de/PDF/Diplomarbeit-MK-1.0-net.pdf
ah, now this looks interesting. from a quick glance, is this just a
theoretical concept, or has it been implemented? we have *some* JFFS2
space available, but not a guaranteed amount. if this requires a
completely separate JFFS2 partition, we might not be able to handle
that.
quoted
but is it feasible to redefine the layout of that flash chip and
take, say, 4M of it and create a JFFS2 filesystem, then put the root
filesystem in there uncompressed? (assuming, of course, that the
Standard JFFS2 code will always compress.
sorry, i'm not sure what you're saying here. are you saying that i
can create a compressed JFFS2 image of my root filesystem on my build
host, just as i do when i create my zImage.initrd? or just compress
the individual files in the filesystem? and have this filesystem
automatically loaded into, and mounted from, RAM? can you clarify
this?
This is a pretty standard setup. Although I don't really recommend to
use JFFS2 for root filesystem (for example, because with a big root
filesystem the boot time may deteriorate).
that was one of my concerns -- not just the boot time but the run
time, even if i could structure it as read-only.
Instead, we usually split the stuff in a read-only partition (for
example cramfs), a volatile part (tmpfs), and a persistent storage
partition (JFFS2).
that's awfully close to what we're doing now. we've got the tmpfs, we
have a completely separate flash for persistent apps and data, it's
just the root filesystem that i would *dearly* love to be able to
patch on the fly on a running system. i'll look a lot more closely
into the above. thanks.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, 28 Jun 2004, David Woodhouse wrote:
On Mon, 2004-06-28 at 09:09 +0200, Wolfgang Denk wrote:
quoted
quoted
is this possible? anyone done it this way, and can tell me what
pitfalls i have to watch for? thanks.
This is a pretty standard setup. Although I don't really recommend to
use JFFS2 for root filesystem (for example, because with a big root
filesystem the boot time may deteriorate). Instead, we usually split
the stuff in a read-only partition (for example cramfs), a volatile
part (tmpfs), and a persistent storage partition (JFFS2).
I think it should be OK when it's 4MiB in size. Mount time was far more
of a problem in JFFS2 many years ago when people were using the 2.4
kernel. It's a lot faster in 2.6.
There's people looking at making it even faster now, too.
we're still using the 2.4 kernel here, but i don't think boot/mount
time is an issue. i mean, someone's just going to turn the unit on,
wait to get a "READY" prompt, and go to work. if it takes a bit
longer, tough. :-)
it was more the response time from flash as opposed to RAM that was an
issue for me. that's why i was asking about having the root FS loaded
from flash into RAM at boot time. we'd probably be happy about
sacrificing boot time response (copying all of the root FS into RAM)
for better run time performance, although i don't know the differences
in performance at the moment.
but i like the fact that it's snappier under 2.6.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, 28 Jun 2004, David Woodhouse wrote:
I think it should be OK when it's 4MiB in size. Mount time was far more
of a problem in JFFS2 many years ago when people were using the 2.4
kernel. It's a lot faster in 2.6.
this is yet another reason why i'm keen on getting that 2.6 kernel
running on my board. so far, i still get a full kernel boot, then a
brief foray into user space to start minit, then ... hang.
so i'll just keep pulling the latest updates and keep trying.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/