Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 7:21 PM, Mikus Grinbergs mi...@bga.com wrote: Downsides - Increased SD card wear For about two years now, I've been defining a swap partition on the (external) permanent SD card I use with my XO-1 systems. So far, I have never experienced any problems with that setup. My experience thus far, single partition with ext2(noatime), swap as a file in /swap.img, 384MiB. The advantage is to relieve memory pressure. In particular, I am a heavy user of 'yum' - and that swap space (together with judicious specification for /var/cache/yum) allows me to run HUGE yum installs. Indeed. Or general website viewing. Web browsers don't seem particularly memory efficient these days. Tiago mikus p.s. By the way, I also had a swap partition on the (external) permanent SD card I had in an XO-1.5. But unless running an unreasonable number of Activities simultaneously, I do not recall ever seeing that swap partition on the XO-1.5 being used -- apparently the larger RAM size on the XO-1.5 rarely gets into memory pressure. ___ 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: SD card unpartitioned space -- used for swap?
BTW, the card is a Sandisk 4GiB Class 2, bought used on eBay. First one bought for installing OSs, going stronger where others have failed with a lot less use. Approximately 1GiB is free, not touching the NAND for anything other than testing new XO OS releases. Tiago On Mon, Dec 6, 2010 at 12:25 AM, Tiago Marques tiago...@gmail.com wrote: On Mon, Nov 22, 2010 at 7:21 PM, Mikus Grinbergs mi...@bga.com wrote: Downsides - Increased SD card wear For about two years now, I've been defining a swap partition on the (external) permanent SD card I use with my XO-1 systems. So far, I have never experienced any problems with that setup. My experience thus far, single partition with ext2(noatime), swap as a file in /swap.img, 384MiB. The advantage is to relieve memory pressure. In particular, I am a heavy user of 'yum' - and that swap space (together with judicious specification for /var/cache/yum) allows me to run HUGE yum installs. Indeed. Or general website viewing. Web browsers don't seem particularly memory efficient these days. Tiago mikus p.s. By the way, I also had a swap partition on the (external) permanent SD card I had in an XO-1.5. But unless running an unreasonable number of Activities simultaneously, I do not recall ever seeing that swap partition on the XO-1.5 being used -- apparently the larger RAM size on the XO-1.5 rarely gets into memory pressure. ___ 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: SD card unpartitioned space -- used for swap?
That's strange, wherever I have used flash memory to serve as boot drive, the kernel/userspace waits for the writes to be complete before powering down. I have not experienced corruption that looks anything similar to what's described. So the software is thinking it has written it but it doesn't? Best regards, Tiago On Wed, Nov 24, 2010 at 2:53 PM, Richard A. Smith rich...@laptop.orgwrote: On 11/22/2010 07:20 PM, James Cameron wrote: Also, I'm not familiar with evil keepout time. But note that on the new XO-1 F14 build, the shutdown time-lapse is only a few seconds. If actually 30s are needed to keep the SD circuitry happy, perhaps a delay (and a Release Notes explanation) should be added to the OLPC. I suspect the evil keepout time is the time after the last write request to the card and the removal of power. It is why current XO-1.5 EC firmware blinks the power LED for some seconds on power off. Its 3 seconds and only active for internal uSD. You need really new 1.5 firmware to have this delay. If you are running on external SD there is at least one 8 gig card with a flash controller (which could be in multiple different cards) that will become completely unusable if you power it off less than 2 seconds or so from the last write. I recommend you do hard power offs little as possible. Suspend/resume also should be disabled. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ 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: SD card unpartitioned space -- used for swap?
Hi, That's strange, wherever I have used flash memory to serve as boot drive, the kernel/userspace waits for the writes to be complete before powering down. I have not experienced corruption that looks anything similar to what's described. So the software is thinking it has written it but it doesn't? There are two separate transitions, and you're each talking about a different one: (1) From kernel to flash device: * This can be waited on as you describe, because the kernel knows when its dirty page cache has been written to the device. sync and reboot/shutdown all wait on this completing before they return. (2) From flash device to flash media: * The flash device has internal memory that it uses to stage blocks to be written to the media. The kernel can't know when this is happening, because it happens internally to the flash device. We've found instances of flash devices where you need to continue providing power for two seconds after (1) has finished, such that (2) can finish before power is lost, else corruption happens. (Requiring this is in violation of the relevant specs, but that's hardware for you.) - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Dec 6, 2010 at 1:04 AM, Chris Ball c...@laptop.org wrote: Hi, That's strange, wherever I have used flash memory to serve as boot drive, the kernel/userspace waits for the writes to be complete before powering down. I have not experienced corruption that looks anything similar to what's described. So the software is thinking it has written it but it doesn't? There are two separate transitions, and you're each talking about a different one: (1) From kernel to flash device: * This can be waited on as you describe, because the kernel knows when its dirty page cache has been written to the device. sync and reboot/shutdown all wait on this completing before they return. (2) From flash device to flash media: * The flash device has internal memory that it uses to stage blocks to be written to the media. The kernel can't know when this is happening, because it happens internally to the flash device. We've found instances of flash devices where you need to continue providing power for two seconds after (1) has finished, such that (2) can finish before power is lost, else corruption happens. (Requiring this is in violation of the relevant specs, but that's hardware for you.) That behavior is what I would assume as the normal one but well, if it's that way. Seems like somebody forgot to add some type of capacitor in their SD card design. Perhaps this is an issue tied to micro SD cards, which have less room for somewhat redundant data structures in the application of cell phones and cameras. Tiago - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Dec 06, 2010 at 12:30:52AM +, Tiago Marques wrote: That's strange, wherever I have used flash memory to serve as boot drive, the kernel/userspace waits for the writes to be complete before powering down. I have not experienced corruption that looks anything similar to what's described. So the software is thinking it has written it but it doesn't? It's not visible corruption as such, since the card becomes completely unusable, no read, no write, no response. Bricked card. Chris explained well but I'll phrase it another way; it's a hardware problem with the card, combined with our pattern of use in manufacturing tests, combined with a lack of specification adherence for the workaround which the card manufacturer asked us to deploy. It might also relate to a problem recently detected, where certain SD cards do not properly reset when used in an XO. See http://dev.laptop.org/ticket/10512 XO-1.5 and XO-1.75 A1 external SD card slot does not discharge supply. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On 11/22/2010 07:20 PM, James Cameron wrote: Also, I'm not familiar with evil keepout time. But note that on the new XO-1 F14 build, the shutdown time-lapse is only a few seconds. If actually 30s are needed to keep the SD circuitry happy, perhaps a delay (and a Release Notes explanation) should be added to the OLPC. I suspect the evil keepout time is the time after the last write request to the card and the removal of power. It is why current XO-1.5 EC firmware blinks the power LED for some seconds on power off. Its 3 seconds and only active for internal uSD. You need really new 1.5 firmware to have this delay. If you are running on external SD there is at least one 8 gig card with a flash controller (which could be in multiple different cards) that will become completely unusable if you power it off less than 2 seconds or so from the last write. I recommend you do hard power offs little as possible. Suspend/resume also should be disabled. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On 11/24/2010 09:53 AM, Richard A. Smith wrote: or so from the last write. I recommend you do hard power offs little as possible. Suspend/resume also should be disabled. My statement is not 100% accurate. The external SD card can remain powered in suspend so you don't have to disable sus/res totally but you do have to make sure that is enabled. I'm not sure what the default is. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
Assuming OLPC isn't using TRIM support on the SD cards, writes to the swap space are indistinguishable from writes to any other space on the card. That means that writes to the swap partition could potentially corrupt other data on the card, especially if it occurs less than 30s before removal of power (or whatever that evil keepout time is). From my recent experience, I wouldn't be too worried about swap space wearing out the SD card, as we used to -- but that's not to say it's 100% safe, all reads and writes are risky to some degree. We've seen up to 60s delays on reads from flash as well, you might consider how that might affect perceived performance. FWIW, litl also uses a no-swap-space linux setup. We haven't actually had any problems with it; bugs I thought I could pin on low-memory/no-swap issues turned out to actually be bugs in the Atom page table hardware (!) which were exacerbated when lots of page table operations were done -- in our case, GPU-heavy tasks triggered the bug just as well. Our superstitions about OLPC's no-swap configuration may well prove to be similarly unfounded. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 11:32 AM, C. Scott Ananian csc...@laptop.org wrote: just as well. Our superstitions about OLPC's no-swap configuration may well prove to be similarly unfounded. Just to clarify -- side-to-side comparison in the past have shown a significant improvement. We did get a specially bad-behaving kernel in our F7 builds in that regard, but even F9 builds have shown it to be better. Note that this is not only Sugar. Wise or not, we are shipping XOs with Gnome. Specially with the HS model, you can fully expect people to want to use OO.org . cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On 22 November 2010 16:41, Martin Langhoff martin.langh...@gmail.com wrote: Just to clarify -- side-to-side comparison in the past have shown a significant improvement. We did get a specially bad-behaving kernel in our F7 builds in that regard, but even F9 builds have shown it to be better. That was an XO-1 comparison though. I haven't heard of similar problems existing for XO-1.5, but my field experience there is much less. Are there known situations where adding swap actually helps? Another thing to consider would be the current series of patches going into Linux that improve interactivity under high CPU/memory pressure. Certainly candidates for inclusion if we can briefly show their value. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
As my own clarification: I wasn't dismissing possible performance improvements (of any kind). I was just commenting on the old lockup bugs, saying this might not actually be related to no-swap-space, although it's possible memory pressure exacerbates the problem. For performance issues, you have to balance against the risks. If it enables you to run ooo, maybe it's worth it. It seems you might also be introducing a configuration management issue, though, where only some units with a given SKU can run (say) OOo. --scott On Monday, November 22, 2010, Daniel Drake d...@laptop.org wrote: On 22 November 2010 16:41, Martin Langhoff martin.langh...@gmail.com wrote: Just to clarify -- side-to-side comparison in the past have shown a significant improvement. We did get a specially bad-behaving kernel in our F7 builds in that regard, but even F9 builds have shown it to be better. That was an XO-1 comparison though. I haven't heard of similar problems existing for XO-1.5, but my field experience there is much less. Are there known situations where adding swap actually helps? Another thing to consider would be the current series of patches going into Linux that improve interactivity under high CPU/memory pressure. Certainly candidates for inclusion if we can briefly show their value. Daniel -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
Downsides - Increased SD card wear For about two years now, I've been defining a swap partition on the (external) permanent SD card I use with my XO-1 systems. So far, I have never experienced any problems with that setup. The advantage is to relieve memory pressure. In particular, I am a heavy user of 'yum' - and that swap space (together with judicious specification for /var/cache/yum) allows me to run HUGE yum installs. mikus p.s. By the way, I also had a swap partition on the (external) permanent SD card I had in an XO-1.5. But unless running an unreasonable number of Activities simultaneously, I do not recall ever seeing that swap partition on the XO-1.5 being used -- apparently the larger RAM size on the XO-1.5 rarely gets into memory pressure. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 11:03:26AM -0500, Martin Langhoff wrote: - Slightly longer first boot - Slightly more fragile first boot (can we make it failsafe?) There's no reason to do this during boot. The new partition can be added after boot, followed by mkswap and swapon. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
Assuming OLPC isn't using TRIM support on the SD cards, writes to the swap space are indistinguishable from writes to any other space on the card. That means that writes to the swap partition could potentially corrupt other data on the card, especially if it occurs less than 30s before removal of power (or whatever that evil keepout time is). If indistinguishable is true, then there is as much wear to the SD card from one file-block written as there is from one swap-block written. I have no measurements whatsoever - but my gut feel is that the majority of my SD card writes are for file-blocks. If that happens to be the case, then writes to swap space are a minor wear contributor. Also, I'm not familiar with evil keepout time. But note that on the new XO-1 F14 build, the shutdown time-lapse is only a few seconds. If actually 30s are needed to keep the SD circuitry happy, perhaps a delay (and a Release Notes explanation) should be added to the OLPC. To advance the discussion, collecting a quantitative measure of average swap writes per day given some usage profile would let you more-or-less rigorously determine whether swap was 'safe' over the 5 year expected lifetime of the device. Note: I'm using an external SD card. So if it fails before the OLPC itself fails, I can at reasonable expense replace this swap device -- I don't have to plan for a definite wear lifetime. If you started collecting/recording total data written to your swap partition, I'd be very interested to hear (in a month or so) what your numbers were. I'm NOT into instrumentation. Please help me in locating software that will collect the number of swap (and file) writes to a physical device -- but it must be software that is simple_for_me_to_install_on_OLPC. [For persistence, the output of that software needs to go to the SD.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 6:43 PM, Mikus Grinbergs mi...@bga.com wrote: If indistinguishable is true, then there is as much wear to the SD card from one file-block written as there is from one swap-block written. Yes. I have no measurements whatsoever - but my gut feel is that the majority of my SD card writes are for file-blocks. If that happens to be the case, then writes to swap space are a minor wear contributor. Measurements are always helpful. Also, I'm not familiar with evil keepout time. But note that on the new XO-1 F14 build, the shutdown time-lapse is only a few seconds. If actually 30s are needed to keep the SD circuitry happy, perhaps a delay (and a Release Notes explanation) should be added to the OLPC. This is an issue with particular brands of SD cards. It's not an XO issue, per se. To advance the discussion, collecting a quantitative measure of average swap writes per day given some usage profile would let you more-or-less rigorously determine whether swap was 'safe' over the 5 year expected lifetime of the device. Note: I'm using an external SD card. So if it fails before the OLPC itself fails, I can at reasonable expense replace this swap device -- I don't have to plan for a definite wear lifetime. Are you making regular backups? If you started collecting/recording total data written to your swap partition, I'd be very interested to hear (in a month or so) what your numbers were. I'm NOT into instrumentation. Please help me in locating software that will collect the number of swap (and file) writes to a physical device -- but it must be software that is simple_for_me_to_install_on_OLPC. [For persistence, the output of that software needs to go to the SD.] The contents of /proc/diskstats seem to contain the interesting info. http://www.linuxquestions.org/questions/suse-novell-60/interpreting-proc-diskstats-360350/ describes their interpretation. A user-friendly script would probably live in /etc/init.d and record the relevant information from /proc/diskstats at shutdown time. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 05:43:18PM -0600, Mikus Grinbergs wrote: Assuming OLPC isn't using TRIM support on the SD cards, writes to the swap space are indistinguishable from writes to any other space on the card. That means that writes to the swap partition could potentially corrupt other data on the card, especially if it occurs less than 30s before removal of power (or whatever that evil keepout time is). ... Also, I'm not familiar with evil keepout time. But note that on the new XO-1 F14 build, the shutdown time-lapse is only a few seconds. If actually 30s are needed to keep the SD circuitry happy, perhaps a delay (and a Release Notes explanation) should be added to the OLPC. I suspect the evil keepout time is the time after the last write request to the card and the removal of power. It is why current XO-1.5 EC firmware blinks the power LED for some seconds on power off. We only know it affects the cards we ship, and no idea if it affects that external card you're using. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
