From: Markus S. <msv...@ae...> - 2010-09-26 21:48:46
|
Dear gumstix-users, I'm experimenting with the Overo Air and Tobi board. I would like to have a simple device, which can be powered on and off at any time, without requiring a "shutdown now" from the command prompt, to ensure that the file system is in a clean state for the next power on. At the moment, if I power down the Overo by unplugging the 5V supply, then on next boot the file system is usually mounted read-only. Only when I shut down cleanly, and reboot, does it become writable again. How can I set up the system, so that it's possible to turn the device on and off, without requiring a reboot or running fsck to fix up the file system? I imagine it would involve using multiple partitions, probably one partition with volatile data being mounted into a RAM disk or something. It seems tricky, because things like the DHCP client appear to write data to a file somewhere (I noticed that the Overo does not connect to the LAN using DHCP if the file system mounts read-only). Alternately, I could see a hardware solution, where a GPIO is used to detect when the power supply shuts off, and a small back-up power source remains active long enough to execute a clean shutdown. This is probably more a general Linux question than specifically Gumstix, but I would think that someone on this mailing list has tried and succeeded to do something similar. Many thanks, Markus. |
From: Ned F. <nfo...@wh...> - 2010-09-26 22:54:38
|
On 09/26/2010 05:48 PM, Markus Svilans wrote: > Dear gumstix-users, > > I'm experimenting with the Overo Air and Tobi board. I would like to > have a simple device, which can be powered on and off at any time, > without requiring a "shutdown now" from the command prompt, to ensure > that the file system is in a clean state for the next power on. > > At the moment, if I power down the Overo by unplugging the 5V supply, > then on next boot the file system is usually mounted read-only. Only > when I shut down cleanly, and reboot, does it become writable again. > > How can I set up the system, so that it's possible to turn the device on > and off, without requiring a reboot or running fsck to fix up the file > system? I have no experience with the Overo or with OE builds, but I routinely power cycle my Connex and never have any trouble with it at all. It still runs the old 2.6.20 kernel and has a jffs (or maybe it's jffs2) file system, as it was originally configured. -- Ned Forrester nfo...@wh... Oceanographic Systems Lab 508-289-2226 Office / 774-392-5352 Cell Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 |
From: Markus S. <msv...@ae...> - 2010-09-26 23:04:25
|
Hi Ned, On 2010.09.26 18:54, Ned Forrester wrote: > I have no experience with the Overo or with OE builds, but I routinely > power cycle my Connex and never have any trouble with it at all. It > still runs the old 2.6.20 kernel and has a jffs (or maybe it's jffs2) > file system, as it was originally configured. That's very interesting. I am having this problem when using a Micro SD card formatted per the instructions on the Gumstix developer site: http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html Those instructions tell you to format the file system partition in ext3. Perhaps there is some advantage to using jffs2? Regards, Markus. |
From: Ned F. <nfo...@wh...> - 2010-09-27 04:24:31
|
On 09/26/2010 07:04 PM, Markus Svilans wrote: > Hi Ned, > > On 2010.09.26 18:54, Ned Forrester wrote: >> I have no experience with the Overo or with OE builds, but I routinely >> power cycle my Connex and never have any trouble with it at all. It >> still runs the old 2.6.20 kernel and has a jffs (or maybe it's jffs2) >> file system, as it was originally configured. > > That's very interesting. > > I am having this problem when using a Micro SD card formatted per the > instructions on the Gumstix developer site: > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > Those instructions tell you to format the file system partition in ext3. > Perhaps there is some advantage to using jffs2? I'm not sure what the modern wisdom is, but jffs2 was designed with some of the issues of flash memory in mind. Incidentally, my experience is with the on-board flash. I also use an MMC card to write a few log files and I have not seen any problem with that either. -- Ned Forrester nfo...@wh... Oceanographic Systems Lab 508-289-2226 Office / 774-392-5352 Cell Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 |
From: Chris W. <whi...@gm...> - 2010-09-27 15:58:31
|
In regards to jffs2, The OE irc channel guys recommended ubifs over jffs2. Trying it out myself, it does seem faster in several instances. I think Koen's quote was something like "jffs2 is fine if you're living in 1999". -chris On Sun, Sep 26, 2010 at 11:24 PM, Ned Forrester <nfo...@wh...> wrote: > On 09/26/2010 07:04 PM, Markus Svilans wrote: >> Hi Ned, >> >> On 2010.09.26 18:54, Ned Forrester wrote: >>> I have no experience with the Overo or with OE builds, but I routinely >>> power cycle my Connex and never have any trouble with it at all. It >>> still runs the old 2.6.20 kernel and has a jffs (or maybe it's jffs2) >>> file system, as it was originally configured. >> >> That's very interesting. >> >> I am having this problem when using a Micro SD card formatted per the >> instructions on the Gumstix developer site: >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >> >> Those instructions tell you to format the file system partition in ext3. >> Perhaps there is some advantage to using jffs2? > > I'm not sure what the modern wisdom is, but jffs2 was designed with some > of the issues of flash memory in mind. Incidentally, my experience is > with the on-board flash. I also use an MMC card to write a few log > files and I have not seen any problem with that either. > > -- > Ned Forrester nfo...@wh... > Oceanographic Systems Lab 508-289-2226 Office / 774-392-5352 Cell > Applied Ocean Physics and Engineering Dept. > Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA > http://www.whoi.edu/ > http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 > http://www.whoi.edu/hpb/Site.do?id=1532 > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Jeff D. <je...@gr...> - 2010-09-27 16:06:40
|
Markus Svilans wrote: > On 2010.09.26 18:54, Ned Forrester wrote: >> I have no experience with the Overo or with OE builds, but I routinely >> power cycle my Connex and never have any trouble with it at all. It >> still runs the old 2.6.20 kernel and has a jffs (or maybe it's jffs2) >> file system, as it was originally configured. > > That's very interesting. > > I am having this problem when using a Micro SD card formatted per the > instructions on the Gumstix developer site: > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > Those instructions tell you to format the file system partition in ext3. > Perhaps there is some advantage to using jffs2? The average Micro SD is not designed for power-loss during a write. Maybe some brands are, but there's no way to find out unless it's in the data sheet. You have no idea what that tiny black box is doing when you tell it to write. It might decide that the sector of a critical filesystem block needs to be moved for wear-leveling in the middle of a write to some other sector. There are removable flash cards specifically designed to recover from a power failure, and of course, they're more expensive. The best you can do without that guarantee is try not to write to the SD when it might be turned off, or make your own hardware solution. That being said, it's unlikely for a critical part of a journaling filesystem to be destroyed by any given power event. The kernel should automatically recover the journal on each boot and continue. Check your boot parameters and kernel logs and make sure it's not being mounted as ext2. jffs2 and ubifs are designed for raw NAND flash, as used onboard the Overo, and will survive a power failure. -- Jeff DeFouw <je...@gr...> Programmer Grand Rapids Technologies |
From: Jeff D. <je...@gr...> - 2010-09-28 20:32:24
|
Jason C. Mecham wrote: > On a Windows Embedded machine you can simply use a Write filter to guarantee that the FS never gets written to unexpectedly. > > For updating you open it to write the files you need to. > > Does Linux have something similar? Nothing with the same interface. The usual strategy is to combine a RAM filesystem (or filesystems) with the main filesystem (the way LiveCD's work) and have your application copy to (or write directly to) real storage when it needs to. -- Jeff DeFouw <je...@gr...> Programmer Grand Rapids Technologies |
From: Søren S. C. <li...@ss...> - 2010-10-03 13:01:49
|
Hi Jeff and Jason, > Nothing with the same interface. The usual strategy is to combine a > RAM filesystem (or filesystems) with the main filesystem (the way >iveCD's > work) and have your application copy to (or write directly to) real storage > when it needs to. I'm not used to MS Write filters, but reading http://technet.microsoft.com/en-us/library/bb932158.aspx I think it would be pretty similar to using a UnionFS (http://en.wikipedia.org/wiki/UnionFS) in Linux? Wouldn't it? Best regards and thanks for clarifying Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |
From: Jason C. M. <jas...@am...> - 2010-09-27 16:34:09
|
On a Windows Embedded machine you can simply use a Write filter to guarantee that the FS never gets written to unexpectedly. For updating you open it to write the files you need to. Does Linux have something similar? -----Original Message----- From: Jeff DeFouw [mailto:je...@gr...] Sent: Monday, September 27, 2010 8:47 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] How to make Overo tolerant to sudden power off Markus Svilans wrote: > On 2010.09.26 18:54, Ned Forrester wrote: >> I have no experience with the Overo or with OE builds, but I routinely >> power cycle my Connex and never have any trouble with it at all. It >> still runs the old 2.6.20 kernel and has a jffs (or maybe it's jffs2) >> file system, as it was originally configured. > > That's very interesting. > > I am having this problem when using a Micro SD card formatted per the > instructions on the Gumstix developer site: > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > Those instructions tell you to format the file system partition in ext3. > Perhaps there is some advantage to using jffs2? The average Micro SD is not designed for power-loss during a write. Maybe some brands are, but there's no way to find out unless it's in the data sheet. You have no idea what that tiny black box is doing when you tell it to write. It might decide that the sector of a critical filesystem block needs to be moved for wear-leveling in the middle of a write to some other sector. There are removable flash cards specifically designed to recover from a power failure, and of course, they're more expensive. The best you can do without that guarantee is try not to write to the SD when it might be turned off, or make your own hardware solution. That being said, it's unlikely for a critical part of a journaling filesystem to be destroyed by any given power event. The kernel should automatically recover the journal on each boot and continue. Check your boot parameters and kernel logs and make sure it's not being mounted as ext2. jffs2 and ubifs are designed for raw NAND flash, as used onboard the Overo, and will survive a power failure. -- Jeff DeFouw <je...@gr...> Programmer Grand Rapids Technologies ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |