Re: multiple MTD partitions
The main reason you have gotten no feedback is because we are ultra-busy right now with mass-production and other issues. I have been looking into partitioning schemes for some time now. We need to have a discussion about this, but now is not the time. Artem Bityutskiy wrote: Hello Mitch, we've sent an UBIFS announcement few days ago to this mailing list: http://lists.laptop.org/pipermail/devel/2007-December/008348.html but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. I'd kindly ask you to help me with booting XO with UBIFS as rootfs. UBI/UBIFS is too large and difficult to implement their support in XO boot-loader. So I plan to use the following scheme: 1. Have 2 MTD partitions - mtd0 and mtd1. mtd0 is small (say, 10MiB), and has JFFS2 FS. It contains /boot, /boot-alt, and everything else which the boot-loader would like to have. mtd1 is large, and it spans up to the end of the flash chip. 2. When booting, the bootloader reads kernel, initrd and the other stuff from the JFFS2 FS on MTD 0. It has to be trivial as the boot-loader already can read JFFS2 FS. The boot-loader does not try to read mtd1, because it contains UBI/UBIFS which it does not support. 3. Once the kernel and initrd are loaded, mtd1 can be attached to UBI and rootfs (UBIFS) can be bounted. Also, I need to be able to easily flash images which contain JFFS2 and UBIFS to the internal NAND. But I guess this has nothing to do with the bootloader, right? Thanks. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
Joel Stanley wrote: It makes a hello of a lot of sense in the scenario you describe. However, how will this positive effect be negated by data loss due to loss of power? There will be times where power is unexpectedly removed, and I would expect this scenario to be common with our user base. JFFS2 has done an excellent job, at least on my xos, of keeping filesystem integrity after sudden power-offs. Joel, Ivan and Bernardo have already made very good explanation on this. Yes, if you mount UBIFS with -o sync flag, you'll end up with the synchronous FS, just like JFFS2. Or your applications have to open files with O_SYNC, or coll functions like fsync(). Yes, JFFS2 is very good in recovery, and this comes very naturally from its simple design. In UIFS we have whole subsystem which is responsible for recovery after unclean reboots (fs/ubis/recovery.c). To recover, UBIFS has to replay the journal and remove all the garbage from the flash media. The garbage are the half-written UBIFS nodes in the journal (very similar to JFFS2 nodes). While JFFS2 leaves garbage on the media and prints CRC error messages on every reboot, UBIFS cleans it up during recovery procedure. Design-wise, I may also add that UBIFS journal is like a small JFFS2 inside UBIFS. From time to time the journal is committed, which means the indexing data structures are updated. The commit process is atomic. And the commit does not involve double copying of the journal data, the data physically sits at the same place, but gets indexed, and UBIFS picks other logical eraseblocks for the next journal. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
ext Bernardo Innocenti wrote: Artem Bityutskiy wrote: but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. It would be great to have a demo OS image using UBIFS. I can't help for the partitioning thing, but if you need help with the process of rebuilding OS images, I just wrote this documentation that may be helpful: http://wiki.laptop.org/go/Building_custom_images Well, we have made one, and I sent an URL to the XO image :-) Although we fixed some bugs since that time, that image is still OK to try. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
Joel Stanley wrote: On Dec 17, 2007 5:55 PM, Ivan Krstić krstic at solarsail.hcs.harvard.edu wrote: On Dec 17, 2007, at 1:51 AM, Joel Stanley wrote: JFFS2 has done an excellent job, at least on my xos, of keeping filesystem integrity after sudden power-offs. Write-back caching does not adversely affect filesystem *integrity*. Okay. Data-loss what what my brain thought, a sentence about integrity came out of my fingers. more context-sensitive policy can be implemented by more context-aware elements of the stack. That would be cool. But I think there would as many, maybe more, cases of batteries being removed, power cords yanked, and generators turning off causing shutdowns than low-battery issues. Also, a point wad made: the more writes you defer, the more memory is used to store them, on an already memory-constrained system. I think writeback would be triggered when memory is needed, so that the memory would be made available anyway. Not that I don't think UBIFS would be awesome, with an amount of tweaking to hit the sweet spot miniamsing memory usage, data-loss, and keeping write speed up, etc. Just thinking about the downsides. Joel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
I know what a write-back buffer is... But I would never characterize a filesystem's write throughput as the peak bandwidth when writing into the buffer. (That's a marketing trick.) Extended writes either fill up memory or degrade to a number which is more reasonable to compare to the write bandwidth of JFFS2. wad On Dec 17, 2007, at 3:06 AM, Artem Bityutskiy wrote: Joel Stanley wrote: It makes a hello of a lot of sense in the scenario you describe. However, how will this positive effect be negated by data loss due to loss of power? There will be times where power is unexpectedly removed, and I would expect this scenario to be common with our user base. JFFS2 has done an excellent job, at least on my xos, of keeping filesystem integrity after sudden power-offs. Joel, Ivan and Bernardo have already made very good explanation on this. Yes, if you mount UBIFS with -o sync flag, you'll end up with the synchronous FS, just like JFFS2. Or your applications have to open files with O_SYNC, or coll functions like fsync(). Yes, JFFS2 is very good in recovery, and this comes very naturally from its simple design. In UIFS we have whole subsystem which is responsible for recovery after unclean reboots (fs/ubis/recovery.c). To recover, UBIFS has to replay the journal and remove all the garbage from the flash media. The garbage are the half-written UBIFS nodes in the journal (very similar to JFFS2 nodes). While JFFS2 leaves garbage on the media and prints CRC error messages on every reboot, UBIFS cleans it up during recovery procedure. Design-wise, I may also add that UBIFS journal is like a small JFFS2 inside UBIFS. From time to time the journal is committed, which means the indexing data structures are updated. The commit process is atomic. And the commit does not involve double copying of the journal data, the data physically sits at the same place, but gets indexed, and UBIFS picks other logical eraseblocks for the next journal. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
John Watlington wrote: I know what a write-back buffer is... But I would never characterize a filesystem's write throughput as the peak bandwidth when writing into the buffer. (That's a marketing trick.) We neither. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
ext Walter Bender wrote: but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. I think you would be well served by making it clearer to people what the goals are of UBIFS relative to existing systems, such as JFFS2, on the XO. This may motivate more people to both do the testing and it may help better focus the feedback. Well, because the mail was _not_ an announcement of a new FS which is ready to be used in production, I sent the mail to the _devel_ mailing list, mostly for the people who know JFFS2 limitations, and who really need something better. But you are right, let me put the things from the userspace developers' perspective. Here are UBIFS goals: = 1. Better scalability 2. Fast write speed Goal 1 was not fully achieved - we need UBI2 for this. But to compare: * JFFS2: XO boots from about 1m 10 secs (when you have freshly flashed FS image) to ~ 4 minutes when your NAND flash is almost full * UBIFS: XO boot time is 1m and this does not depend on what you have on your FS Note, I did not include the time which the bootloader takes, IOW, I started counting time from the moment when the white screen disappears. On OLPC, UBI takes 2 seconds to attach flash, and UBIFS takes ~ 0.2 seconds to mount. Vs. goal 2: UBIFS write speed is about 70MiB/second, because of the write-back support. IOW, UBIFS is similar to traditional FSes like ext2, which have internal buffers and make writes fast. To compare, JFFS2 write speed on XO is about 1.3 MiB/s, because it is always synchronous. At the moment, JFFS2 beats UBIFS on synchronous writes. This is partially because JFFS2 is incorrect (it does not sync write-buffer on each write in case of O_SYNC-opened files - we've just discovered this), and partially because of some mistakes in UBIFS which we are going to fix. Here are JFFS2 drawbacks I thought developers know about: = 1. Long mount time, which depends on what you have in your file system. 2. Big files are opened for long lime - create a 300MiB file, reboot, and try 'time stat file'. 3. Huge dependency on 4. 100% CPU usage my jffs2_mtd0 thread for about a minute after mount 5. Slow writes 6. Limited mmap support: MAP_SHARED is not supported. 7. It is easy to kill JFFS2-based system with a command like: dd if=/dev/zero of=file - it will run out of RAM at some point and the system will die at some point. None of these drawbacks are present in UBIFS, at least on XO. Well, there is some price you have to pay - amount of available flash space is about 5% less then in case of JFFS2. Other advantages of UBI/UBIFS stack === 1. You may enable/disable compression on per inode basis. E.g., if you have an mp3 file, it makes zero sense to try to compress it, and you disable compression. 2. UBI gives you dynamic volumes, just like LVM. And you do not have to have one huge / partition which takes whole flash - you may have different volume for different stuff. This makes SW update easier - e.g., you do not have to backup /home. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
David Woodhouse wrote: http://git.infradead.org/?p=openfirmware.git;a=commitdiff;h=a0b5a7b0c OpenFirmware boots from the partition named 'boot' in the RedBoot partition table. The rest are yours to play with as you see fit. Thanks David, I'll take a look at this. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
Artem Bityutskiy wrote: but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. It would be great to have a demo OS image using UBIFS. I can't help for the partitioning thing, but if you need help with the process of rebuilding OS images, I just wrote this documentation that may be helpful: http://wiki.laptop.org/go/Building_custom_images -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Dec 16, 2007, at 6:08 AM, Artem Bityutskiy wrote: Vs. goal 2: UBIFS write speed is about 70MiB/second, because of the write-back support. IOW, UBIFS is similar to traditional FSes like ext2, which have internal buffers and make writes fast. To compare, JFFS2 write speed on XO is about 1.3 MiB/s, because it is always synchronous. I'm curious how you measured this, as the underlying hardware only supports a max. transfer rate of around 20 MiB/s... wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Dec 16, 2007, at 11:40 PM, John Watlington wrote: I'm curious how you measured this, as the underlying hardware only supports a max. transfer rate of around 20 MiB/s... As Artem mentioned, UBIFS employs a write-back cache, meaning writes aren't flushed to the underlying medium immediately; pages are instead marked dirty in the page cache and written back when evicted. This makes a hell of a lot of sense. In a synchronous filesystem like JFFS2, constant and repeated writes to the same single page will keep pummeling the underlying flash needlessly. With UBIFS, such writes succeed instantly but only cause a write/erase cycle on the flash to be triggered when the page gets kicked out of the page cache either because the RAM is needed or because of the kernel thread performing dirty page writeback on a timer. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Dec 17, 2007 4:46 PM, Ivan Krstić [EMAIL PROTECTED] wrote: This makes a hell of a lot of sense. In a synchronous filesystem like JFFS2, constant and repeated writes to the same single page will keep pummeling the underlying flash needlessly It makes a hello of a lot of sense in the scenario you describe. However, how will this positive effect be negated by data loss due to loss of power? There will be times where power is unexpectedly removed, and I would expect this scenario to be common with our user base. JFFS2 has done an excellent job, at least on my xos, of keeping filesystem integrity after sudden power-offs. Joel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Dec 17, 2007, at 1:51 AM, Joel Stanley wrote: JFFS2 has done an excellent job, at least on my xos, of keeping filesystem integrity after sudden power-offs. Write-back caching does not adversely affect filesystem *integrity*. It makes a tradeoff by reducing flash write/erase frequency and increasing apparent filesystem performance at the cost of more recently-written data potentially being lost in case of power failure. This tradeoff is eminently reasonable as a default policy. Remember that programs can still call fsync to force a flush to flash, and that more context-sensitive policy can be implemented by more context-aware elements of the stack. OHM could, for instance, remount the filesystem synchronously when battery charge goes below a threshold, or it can simply twiddle the /proc twaddle that twuddles the writeback timer twoddle. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Dec 17, 2007, at 2:44 AM, Joel Stanley wrote: That would be cool. But I think there would as many, maybe more, cases of batteries being removed, power cords yanked, and generators turning off causing shutdowns than low-battery issues. Batteries getting removed with no AC should not be a very frequent occurrence, one would think. Yes, it'll happen, but treating it as the case to optimize for seems ill-advised. Also, a point wad made: the more writes you defer, the more memory is used to store them, on an already memory-constrained system. This is irrelevant. The page cache is just a cache -- it shrinks in response to actual memory pressure. If applications gobble up all the RAM, the page cache is small enough as to make the FS effectively become synchronous. Applications don't suffer by having less RAM to go around. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. I think you would be well served by making it clearer to people what the goals are of UBIFS relative to existing systems, such as JFFS2, on the XO. This may motivate more people to both do the testing and it may help better focus the feedback. thanks. -walter -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Fri, 2007-12-14 at 09:54 +0200, Artem Bityutskiy wrote: UBI/UBIFS is too large and difficult to implement their support in XO boot-loader. So I plan to use the following scheme: 1. Have 2 MTD partitions - mtd0 and mtd1. mtd0 is small (say, 10MiB), and has JFFS2 FS. It contains /boot, /boot-alt, and everything else which the boot-loader would like to have. mtd1 is large, and it spans up to the end of the flash chip. 2. When booting, the bootloader reads kernel, initrd and the other stuff from the JFFS2 FS on MTD 0. It has to be trivial as the boot-loader already can read JFFS2 FS. http://git.infradead.org/?p=openfirmware.git;a=commitdiff;h=a0b5a7b0c OpenFirmware boots from the partition named 'boot' in the RedBoot partition table. The rest are yours to play with as you see fit. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
