FS#19951 - SSD frienldiness

Attached to Project: Pacman
Opened by Matěj Týč (bubla) - Thursday, 24 June 2010, 11:09 GMT
Last edited by Dan McGee (toofishes) - Thursday, 08 July 2010, 05:24 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.4.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Summary and Info:
Today SSDs are becoming quite common. The trouble is that those drives wear out if you write on them.
The point is that during system upgrades, a package is downloaded to the disc before the installation. Although it is true that a compressed package occupies less space than files inside of it (so it would save like 30% of overhead or such), it would help if pacman is able to perform everything between downloading the package and copying its contents to the disc in RAM in order not to stress the disc.
Most cutting-edge computers with SSDs should have enough RAM so this could make some sense.
This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 08 July 2010, 05:24 GMT
Reason for closing:  Won't implement
Additional comments about closing:   FS#8586  should quell many of these concerns, as should using tmpfs mounts appropriately
Comment by Dan McGee (toofishes) - Thursday, 24 June 2010, 12:00 GMT
Huge -1 from me. I wouldn't touch an SSD that can't handle the writing of 1 package file to disk. You have absolutely crap hardware if this is the case and you've bought into the BS you've find on the Internet.

If you think this is a good place for savings, let me tell you about all the other things that would be 1000x worse for your disk...
Comment by Matěj Týč (bubla) - Thursday, 24 June 2010, 12:30 GMT
Well, I don't know. It doesn't seem to be a well understood issue after all, see the link below (... systems-level experience from real world use isn't available yet)
http://serverfault.com/questions/142188/can-an-ssd-notify-the-hosting-os-that-its-wear-level-is-getting-high
I have a good MLC SSD (at least I think so, it is 64GB Kingston V-Series), but the system update is IMHO the highest write traffic I have (at least in my case).
The entire /var/cache/pacman directory can get quite big and its size illustrates the issue. Everything that got written there is usually not useful and SSDs do wear out whether one likes it or not, which may mean not only failiure in the far future, but gradual performance degradation now (they write something about this in the link below)...
http://www.hardwarereview.net/Reviews/Kingston V-Plus SSD/KingstonVPlusReview.htm

If you could name those "1000x worse things", go ahead.
I am aware that it might not be worth the effort, but I still don't think that it is essentially a stupid idea...
Comment by Dan McGee (toofishes) - Thursday, 24 June 2010, 12:46 GMT
1. Logging in /var/log/
2. Pacman database in /var/lib/pacman
3. Installing packages ("high write traffic" has a lot less to do with file size and a lot more to do with # of writes)
Comment by Allan McRae (Allan) - Saturday, 26 June 2010, 05:40 GMT
I think #2 is the area that would be of most benefit in terms of SSD wear (although pacman-3.4 does a lot better). This "bug" could be solved by makepkg /var/cache/pacman a tmpfs.
Comment by Matěj Týč (bubla) - Saturday, 26 June 2010, 21:16 GMT
This is slightly off topic, but if logging and stuff is important for SSDs, could you please add some tips (like why is it so bad and how to disable it) to the wiki page about SSDs? I have added some stuff too...
http://wiki.archlinux.org/index.php/SSD#Step_2:_Choosing_a_file_system
Anyway, thank you all if something good emerges out of this.
Comment by Matěj Týč (bubla) - Monday, 28 June 2010, 21:17 GMT
Wow, the amount of data that suddenly appeared on that wiki page is really impressive...
Thank you very much!
Comment by Dan McGee (toofishes) - Thursday, 08 July 2010, 05:12 GMT
Perhaps we can close this out in favor of the tar DB bug, given that we might actually get somewhere with that code this time around? tmpfs for the package cache is a very reasonable solution for this bug as well.
Comment by Allan McRae (Allan) - Thursday, 08 July 2010, 05:20 GMT
That seems fine.

Loading...