Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
Michael.
On Mon, 2008-10-13 at 21:58 -0400, Michael Solberg wrote:
Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
yes, it makes sense to turn it off.
maybe even remove it. -sv
On Mon, 2008-10-13 at 22:13 -0400, seth vidal wrote:
On Mon, 2008-10-13 at 21:58 -0400, Michael Solberg wrote:
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
yes, it makes sense to turn it off.
maybe even remove it.
If you remove it, then it's not present when people install from the live image. Hence, that's a bit of a non-starter
Jeremy
Michael Solberg wrote:
Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
Michael.
This is two separate issues isn't it? Doesn't /var/cache/yum get written to whether you use the applet or yum on the command line?
My understanding of the overlay was that once you write something to it, that space is gone forever, even if you delete those files. So having cache as part of the overlay will just make it fill up quicker. And aren't yum cache hits pretty unlikely? Wouldn't it just be when someone re-installs something they've uninstalled? I would have thought tmpfs is the way to go here - when end users run yum, it's better to re-download than to use up the overlay - once that's gone, you're hosed.
Jeff Weiss
Jeff Weiss wrote:
Michael Solberg wrote:
Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
Michael.
This is two separate issues isn't it? Doesn't /var/cache/yum get written to whether you use the applet or yum on the command line?
My understanding of the overlay was that once you write something to it, that space is gone forever, even if you delete those files. So having cache as part of the overlay will just make it fill up quicker. And aren't yum cache hits pretty unlikely? Wouldn't it just be when someone re-installs something they've uninstalled? I would have thought tmpfs is the way to go here - when end users run yum, it's better to re-download than to use up the overlay - once that's gone, you're hosed.
Jeff Weiss
Er, on second thought there's really not much sense in eating up swap space. Maybe we should just turn off the cache (keepcache=0) ?
I suspect that means it'll always have to download headers, but bandwidth is more plentiful than memory on the XO :)
On Tue, 2008-10-14 at 09:13 -0400, Jeff Weiss wrote:
Er, on second thought there's really not much sense in eating up swap space. Maybe we should just turn off the cache (keepcache=0) ?
This is definitely the best solution.
I suspect that means it'll always have to download headers, but bandwidth is more plentiful than memory on the XO :)
It's true - I do wonder though, is it really feasible to try to do updates on an XO? Six months from now running updates will eat at least 512MB, either blowing out the overlay or the RAM. This will require the user to re-burn the card. Maybe we need a different way to do updates.
Michael.
Michael Solberg wrote:
On Tue, 2008-10-14 at 09:13 -0400, Jeff Weiss wrote:
Er, on second thought there's really not much sense in eating up swap space. Maybe we should just turn off the cache (keepcache=0) ?
This is definitely the best solution.
I suspect that means it'll always have to download headers, but bandwidth is more plentiful than memory on the XO :)
It's true - I do wonder though, is it really feasible to try to do updates on an XO? Six months from now running updates will eat at least 512MB, either blowing out the overlay or the RAM. This will require the user to re-burn the card. Maybe we need a different way to do updates.
Michael.
This is why I was really surprised when I heard we were shipping Live images. I would think an installed image with say, 1.7gb of filesystems and 256mb swap would have been the way to go.
On Tue, 2008-10-14 at 09:29 -0400, Jeff Weiss wrote:
Michael Solberg wrote:
On Tue, 2008-10-14 at 09:13 -0400, Jeff Weiss wrote:
Er, on second thought there's really not much sense in eating up swap space. Maybe we should just turn off the cache (keepcache=0) ?
This is definitely the best solution.
I suspect that means it'll always have to download headers, but bandwidth is more plentiful than memory on the XO :)
It's true - I do wonder though, is it really feasible to try to do updates on an XO? Six months from now running updates will eat at least 512MB, either blowing out the overlay or the RAM. This will require the user to re-burn the card. Maybe we need a different way to do updates.
Michael.
This is why I was really surprised when I heard we were shipping Live images. I would think an installed image with say, 1.7gb of filesystems and 256mb swap would have been the way to go.
I'll try this while I'm testing tonight. I've noticed that the loop filesystems eat a ton of CPU cycles when the system goes into swap.
Does anyone have concrete data on the maximum number of writes on an SD card?
Michael.
On Tue, Oct 14, 2008 at 6:48 AM, Michael Solberg wrote:
I'll try this while I'm testing tonight. I've noticed that the loop filesystems eat a ton of CPU cycles when the system goes into swap.
Does anyone have concrete data on the maximum number of writes on an SD card?
This came up on slashdot a while back. I have not tested myself, but apparently the newer generation of SD have pretty good life, 2 million or so writes per block and built-in wear leveling so that's spread evenly. That's what makes it worth shipping flash-based hard drives in the MacBook Air and similar.
For example, this site tried to come up with a worst case for a 64G disk: "2 million (write endurance) x 64G (capacity) divided by 80M bytes / sec gives the endurance limited life in seconds. The end result is 51 years!" http://www.storagesearch.com/ssdmyths-endurance.html
So it's not as bad as you might fear, but performance is still an issue.
On Tue, 2008-10-14 at 09:13 -0400, Jeff Weiss wrote:
Jeff Weiss wrote:
Michael Solberg wrote:
Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
Michael.
This is two separate issues isn't it? Doesn't /var/cache/yum get written to whether you use the applet or yum on the command line?
My understanding of the overlay was that once you write something to it, that space is gone forever, even if you delete those files. So having cache as part of the overlay will just make it fill up quicker. And aren't yum cache hits pretty unlikely? Wouldn't it just be when someone re-installs something they've uninstalled? I would have thought tmpfs is the way to go here - when end users run yum, it's better to re-download than to use up the overlay - once that's gone, you're hosed.
Jeff Weiss
Er, on second thought there's really not much sense in eating up swap space. Maybe we should just turn off the cache (keepcache=0) ?
keepcache=0 just means that yum will automatically delete package files it has installed/updated. Not that it won't hold a cache.
I suspect that means it'll always have to download headers, but bandwidth is more plentiful than memory on the XO :)
headers have nothing to do with it.
-sv
On Tue, Oct 14, 2008 at 6:30 AM, seth vidal wrote:
On Tue, 2008-10-14 at 09:13 -0400, Jeff Weiss wrote:
Er, on second thought there's really not much sense in eating up swap space. Maybe we should just turn off the cache (keepcache=0) ?
keepcache=0 just means that yum will automatically delete package files it has installed/updated. Not that it won't hold a cache.
I've run into this on servers with small hard disks, too. The only solution I've found is to break the updates into small enough sets for available disk and RAM. When something big like RHEL 4 Update 4 or whatever comes out it may make more sense to rebuild from the new ISOs.
On Tue, 2008-10-14 at 09:04 -0400, Jeff Weiss wrote:
This is two separate issues isn't it? Doesn't /var/cache/yum get written to whether you use the applet or yum on the command line?
My understanding of the overlay was that once you write something to it, that space is gone forever, even if you delete those files. So having cache as part of the overlay will just make it fill up quicker. And aren't yum cache hits pretty unlikely? Wouldn't it just be when someone re-installs something they've uninstalled? I would have thought tmpfs is the way to go here - when end users run yum, it's better to re-download than to use up the overlay - once that's gone, you're hosed.
I think the issue is the applet does it automatically. Yum does it only on demand.
-sv
On Mon, Oct 13, 2008 at 09:58:44PM -0400, Michael Solberg wrote:
Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
I can easily fill the overlay and crash the LiveOS with ext3 errors. Has any thought been put into how to solve this problem?
On Tue, 2008-10-14 at 09:15 -0400, Chuck Anderson wrote:
On Mon, Oct 13, 2008 at 09:58:44PM -0400, Michael Solberg wrote:
Hi!
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide. This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
I can easily fill the overlay and crash the LiveOS with ext3 errors. Has any thought been put into how to solve this problem?
The only real way to solve it is to move away from using dm-snapshot for the overlay and have some form of real unionfs. But that has its own level of "fun" problems that seems to go nowhere fast :/
Jeremy
On Mon, 2008-10-13 at 21:58 -0400, Michael Solberg wrote:
I'm sure someone's thought of this before, but I keep running into this issue on the LiveUSB on the XO.
The issue is that /var/cache/yum is mounted as tmpfs on the Live image. When I log into a desktop session that already knows my wireless key, the updates applet attempts to download all the packages from Rawhide.
It's supposed to be getting turned off already. But there have been a few bugs. Things should be a lot better as of Snap1 or just after based on the traffic in the bug (can't find the # off-hand) although I still need to verify it
This fills the 256MB of RAM pretty quickly and that hangs the machine. Does it make sense to turn that applet off in this case? Or maybe not mount /var/cache/yum as tmpfs when there's an overlay?
Actually, you even *more* want it as tmpfs when there's an overlay. Otherwise, you fill up your overlay and hit other bad error conditions :-/
Jeremy