[opensuse] SSD Upgrade
Thinking of replacing my Drive with a SSD. Probably happen about the time Leap 42.2 comes out. Any words of wisdom here? I'm thinking I'll do the same drill I normally do, Fresh install, then copy /home a and /data over into similar partition sizes that I have before. What to look out for? Any problem with a couple xfs/Luks partitions on the SSD? Brands? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 3 Nov 2016 00:18, John Andersen wrote:
Words is (non-)wisdom(tm): Many wearleveling optimisations from the linux side will not (fully) work with encrypted fs or encrypted partitions, e.g. TRIM. Hint 1: Go for a drive with a high TBW / drive-writes count. Hint 2: overprovisioning (leaving free non-partitioned space) helps. Hint 3: Warranty: 10 years cost (extra) money, 5 years is good sense, 3 years is (very) low. It could be that a MLC drive wins out against TLC one. Further Info startpoint: https://en.wikipedia.org/wiki/Flash_memory#Write_endurance https://en.wikipedia.org/wiki/Multi-level_cell https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning Do not go below 240 GB, as the value per money is (much) worse below that. In the enterprise (datacenter) class I've had little to no problem with the Samsung and Intel drives of the last 3 years, but time will tell - as warranty begins to run out on some of them now. Early Intel was uneven. In the professional (desktop/soho-server) class (10 years warranty), well, no drop out on any drives mounted since 2012, but, see above, time will tell, all on warranty still. In the semi-pro (desktop/soho-server) class (5 years warranty), about 5 per 1000 dropout rate before end-of-warranty (time or TBW reached), seams to be spread all over the manufactureres and the products. In the (IMHO) home-use-only class (less than 5 years warranty, less than 60 Drives-writes TBW), it's a very mixed bag, some charges are very good, but the ones before and after could be crap (same manufacturer, same product). *shrugs* You get wat you pay for. 20 bucks more for a drive with 5 years instead of a 3 year warranty is simply good sense and better sleep. About the same as the tires on your car. - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/02/2016 05:03 PM, Yamaban wrote:
I might just use the drive's own encryption capabilities and abandon luks.
I also saw this: http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-d... He says that all these drives exceed their stated longevity by astounding amounts. Thanks... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/02/2016 05:03 PM, Yamaban wrote:
Hint 2: overprovisioning (leaving free non-partitioned space) helps.
Yamaban... Can you elaborate on this? Wouldn't wear leveling still respect partition boundaries, and unallocated space be ignored? Aren't there enough free-replacement blocks to handle any bad spots that develop? What purpose does unallocated space serve? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Nov 4, 2016 at 6:45 PM, John Andersen <jsamyth@gmail.com> wrote:
John, I don't know if modern SSDs still need that treatment. They may all inherently be over-provisioned? == assuming they aren't You seem to be missing the basics of how a SSD works. There is not a rigid mapping of logical sector addresses to physical storage like there is with a HDD. It's all extremely dynamic and the mapping is updated on every single data write. Not just on bad-spot replacement like on a HDD. There is a queue of unused EBs (erase blocks) that get pulled from on every single data write. Even an update of an already allocated data block causes a new, blank EB to be allocated from the queue for the new data, and the formerly used EB is moved to the back of the queue. It takes several milliseconds for that no-longer useful EB to be erased, so the queue has to be deep enough that that EB isn't needed for some milliseconds. There is NOT an unused EB queue per partition, only one per SSD. If a non-encrypted filesystem is used, the SSD can be told which data blocks are empty and it adds those to the queue of available EBs. Basically for unallocated data blocks, there is no backing store. Thus the EB queue for a SSD with a normal 50% filesystem will have approximately 50% of the EBs in the unused EB queue. SSDs work optimally when the unused EB queue is relatively large. If that queue gets too small, the SSD slows down significantly on writes of any kind. If you are using an encrypted FS, then the SSD doesn't know which data blocks have valid data. Thus every data block has to have an actual backing store and the unused EB queue will be very small. If you over-provision by leaving unallocated partition space, the SSD will leave those data blocks with no backing store and all of those EBs will be kept in the unused EB queue. Hope that helps, Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/04/2016 04:08 PM, Greg Freemyer wrote:
If you are using an encrypted FS, then the SSD doesn't know which data blocks have valid data.
Does this only apply only to something like luks, (operating system crypto)? Or does it also apply to whole drive encryption built into many of these devices? (Most claim no performance degradation using their built in enctryption) (Note that I am dealing with a laptop here so I'm leaning towardd something like these. https://www.amazon.com/dp/B00OBRE5UE/ref=psdc_1292116011_t1_B00LF10KTO or https://www.amazon.com/dp/B00LF10KTO/ref=psdc_1292116011_t3_B00OBRE5UE Thks for info. It confirms my prior understandings.... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Donnerstag, 3. November 2016, 01:03:49 schrieb Yamaban:
TRIM does work with DMCrypt since Kernel 3.1. But there are theoretical security implications: https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt | allow_discards: Allow block discard requests (a.k.a. TRIM) for the crypt device. | The default is to ignore discard requests. | Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later. | Available since: 1.11.0 (kernel 3.1) man crypttab (Leap 42.1) | discard | Allow discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. About hardware full disk encryption (FDE): http://security.stackexchange.com/questions/134564/how-secure-is-hardware-fu... IMHO using hardware FDE is better than nothing and will prevent a common thief from reading the disk of your laptop. Gruß Jan -- He who hesitates is sometimes saved. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Nov 2, 2016 at 7:18 PM, John Andersen <jsamyth@gmail.com> wrote:
Technologies? is a better question. For a lightly loaded PC, most any AHCI SSD will do great. I've mostly been buying Samsung SSDs with a SATA interface. For a state of the art experience that can handle a multi-threaded load like a server can throw at it, you want a NVMe SSD. Those don't have SATA ports, they are made to run at native PCIe speeds. Meaning fast as hell. Here's a year old article about one that was just released back then: http://arstechnica.com/gadgets/2015/10/950-pro-review-samsungs-first-pcie-m-... I have a Asus X.99 Deluxe MB that has a NVMe SSD connector directly on the MB. The SSD plugs into that vertically. (Unlike the picture in the article where the SSD is laying flat.) I have a Samsung PM951 (MZ-VLV1280) 128GB (I bought it to test functionality with, so the cheapest I could find.) I've been running Leap 42.2 (beta => RC1) on that pair since I bought the SSD (in June I think). I have had zero issues with doing so, but I mostly tinker with that machine, so I don't have any meaningful benchmarks. One new thing to learn is the drive is NOT /dev/sda It is /dev/nvme* nvme => Non-Volatile Memory Express nvme0 => The first NVMe SSD nvme0n1 => the first namespace of the first NVMe SSD nvme0n1p1 => The first partition on the first namespace of the NVMe SSD If your MB (like most) doesn't have a connector, you can buy a PCIe adapter for $25 or so dollars. Here's one example: https://www.amazon.com/Ableconn-PEXM2-SSD-NGFF-Express-Adapter/dp/B017JGVTAM... I haven't used an adapter, so no pros/cons from me. I assume they work with older MBs and CPUs. Alright, a quick performance test with my hardware. I was doing some 32-bit openSUSE 13.1 compatibility testing, so I openSUSE 13.1 boot CD booted at the moment. I did: time dd if=/dev/nvme0n1 of=/dev/zero bs=1M count=10000 It took 15.5 seconds to read 10GB., or 675 MB/sec. Again, that's with a 3-year old 32-bit kernel. Booting back to 64-bit Leap 42.2 RC1 9.8 seconds, or 1.1 GB/sec I'm actually surprised the 64-bit speed is that low. HTH Greg Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 02 Nov 2016 04:18:35 PM CDT, John Andersen wrote:
Hi I purchased a SanDisk Extreme Pro SSD 240GB recently; http://www.anandtech.com/show/8170/sandisk-extreme-pro-240gb-480gb-960gb-rev... I have three OCZ's (60 and 120GB) and a Crucial 120GB have many K's of hours now and all running fine. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.34-33-default up 4 days 7:54, 4 users, load average: 0.71, 0.40, 0.28 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 03 Nov 2016, John Andersen wrote:
I'm running Leap 42.2 (RC1) with a SATA Samsung SSD 850 EVO 250GB (AMD Phenom II X6 1090T, 8GB, Nvidia GTX 650 Ti, Seagate ST2000DM001). I'm using ext4 for root (I briefly toyed with btrfs, but backing up it's sub-partition structure proved difficult to retrofit to my simple rsync based backup regime). Btrfs is supposed to better support SSD's (but I gather its not a big deal). I did a fresh install of 42.2 (RC1) and re-applied all my usual settings and packages. It all went smoothly. There seems to be some confusion on the web about Samsung and trim support. My dmesg output contains: [ 3.267504] ata1.00: disabling queued TRIM support [ 3.267511] ata1.00: ATA-9: Samsung SSD 850 EVO 250GB, EMT02B6Q, max UDMA/133 I think this is mainly for older drives, which mine is not. I've decided not to worry about it. I may look into using fstrim (man 8 fstrim) but I'm not sure whether this too might be an issue. The 42.2 kernel build seems to have correctly picked to use the deadline scheduler for the SSD (only): cat /sys/block/sda/queue/scheduler noop [deadline] cfq I decided to put noatime in mount entry in /etc/fstab to reduce writes (some say this is no longer really necessary). My previous OCZ SSD died after 5 years. I've read that SSD's can fail without warning. In my case, the OS just started errorring like crazy and crashed. There was no possibility of recovering anything as the failed drive was no longer recognised. So it would be a good idea to keep backups on other media. I backup the OS to both online and offline hard drives, so I lose a day to a week depending. My SSD failed just after installing Tumbleweed in a spare partition, so perhaps all the new activity pushed the writes over some limit. I still keep /home on a hard drive - being into photography makes SSD to expensive for user space. Cheers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/11/2016 à 00:18, John Andersen a écrit :
don't worry. Take any ssd you can afford (obviously the more expensive may be marginally better). On Leap 42.1 I don't trust BTRFS anymore (if I can't manage a more than 100Gb /) and use ext4. on Leap 42.2 I may try BTRFS and 3 years waranty is enough: you probably wont keep the disk that long. I already have on my drawer a 128 Gb and a 250 Gb ssd, because I now use a 500Gb one... The ssd technology is making better and cheaper so fast... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello
I just ordered a Crucial 525 MX 300 CT525MX300SSD1 SSD last week to install on an old laptop when 42.2 comes out. ### Crucial 525 MX 300 CT525MX300SSD1 Power Consumption Active Read/Write (Average in Watts): ? Note : The power consumption info appears to be a well garded secret. I can only find a reference to 0.075W Power Consumption Active Read/Write Idle (Watts) 0.075? Size: 525 Prix: 119,90 € at amazon.fr Prix/Go: 0.23 € Reliability (TBF) (Million hours): 1.5 Endurance (Total bytes written To): 220 Expected Lifetime writing 10 Go a day 10 : 61.7 years* Waranty 3 Years/160TBW Débit réel Mo/s hdparm -t /dev/sda ? - I have not installed it yet The following quote came off the Web somewhere: "The Crucial MX300 has an endurance of 220TBW, meaning you can write 220 terabytes of data to the drive before it becomes unreliable. To put this in perspective, if you write 50GB of data per day every day to the drive, it will take you some 12 years to wear it out. " [*] The following are my calculations Endurance : 220 To If I make 10GB hot writes per day (I have no idea but whatever), the expected drive life should be approximately (220*1024)/(10*365) = 61.7 years until total drive fault. ### I have also been using a Crucial M550 CT512M550SSD1 - 512 Go SSD on an old Thinkpad since Oct 2014. The machine only runsTumbleweed and it has a Luks encrypted ext4 data partition and I have never experienced any problems. The times I have re installed Tumbleweed, the installation process detects the encypted partition and just asks for the password / key. As a side note, the Crucial M550 CT512M550SSD1 SSD drive cost me almost twice as much € as the new CT525MX300SSD1 and its endurance (Total bytes written To) is only 70 To (compared to 220) so things have definitely improved ! ### I also love Samsung 850 PRO SSD and I have been using one in my main machine for the last 2 years with zero problems and regets. ### Samsung 850 PRO 1TB MZ-7KE1TOBW Power Consumption Active Read/Write (Average in Watts) 3.3W/3.0W Power Consumption Active Read/Write Idle (Watts) 0.4Watt Size: 1024 Prix: 540 € (on sale in Oct 2014); now 469 € Prix/Go: 0,53 € when I bought it (now 0,46 €) Reliability (TBF) (Million hours): 2.0 Endurance (Total bytes written To): 300 Expected Lifetime writing 10 Go a day 10 : 84,2 years* Waranty 10 Years/150TBW [*] The following are my calculations Endurance : 300 To # If I make 10GB hot writes per day (I have no idea but whatever), the expected drive life should be approximately (300*1024)/(10*365) = 84,2 years until total drive fault. My speed specs on a 5 year old motherboard follow : time dd if=/dev/sda1 of=/dev/zero bs=1M count=10000 10000+0 records in 10000+0 records out 10485760000 bytes (10 GB) copied, 18.5969 s, 564 MB/s real 0m18.600s user 0m0.020s sys 0m5.076s # hdparm -t /dev/sda1 /dev/sda1: Timing buffered disk reads: 1616 MB in 3.00 seconds = 538.66 MB/sec Regards James -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-03 00:18, John Andersen wrote:
Thinking of replacing my Drive with a SSD. Probably happen about the time Leap 42.2 comes out.
An addition to the question: What about doing the same on a laptop which double boots with Windows? Is it possible to migrate both Windows and Linux to an SSD from rotating rust? Anybody has done it? Caveats, known issues, suspicions, ideas? I'm toying with the idea of doing it, but that is one of the things that stops me. Another is the "improved" price. Another is the suspicion that an SSD can die of age suddenly, being impossible to recover anything. My idea would be to dd the old disk to the new one. I have done this once on that same laptop using rotating disks of the same model. One problem might be sector size: old is 512B, new might be 4KiB. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, Nov 5, 2016 at 10:16 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
No issues jump out. I've migrated at least 3 windows laptops from rotating to SSD. At least one of the laptops was a dual boot PC
I don't know what your "improved" price comment means. On my day-to-day laptop, I replaced the boot rotating HDD with a SSD, then I removed the optical drive (OD) and used a HDD converter ($20) that fits the OD bay mechanical space to let me put in a 2TB rotating drive. I have my dual boot OS setup on the SSD, but I have VMs and other large data on the HDD.
SSDs don't have the same issues with 4KB that HDDs do. For an SSD, the native block is a EB, and they are way bigger than 4KB. But the SSD hides that so well, I don't think there is even a way for Linux / Windows to leverage knowledge about EBs.
-- Cheers / Saludos,
Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-05 17:04, Greg Freemyer wrote:
Windows often complains if you renew the hard disk thinking that one is using a pirated copy. If the original disk is dd-ed to the new, Windows is happy. But I've never tried with SSD.
Oh, a bit of humour: they are more expensive :-))
Oh.
I have my dual boot OS setup on the SSD, but I have VMs and other large data on the HDD.
I don't store large things on the laptop. No VMs there. So a 500GB unit should suffice. Perhaps more if the price is right. But an extra hard disk... dunno.
Well, as long as the software can think that it is 512 bytes per sector Windows will be happy about fixed position files. And the booter too. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, 3 Nov 2016 00:18, John Andersen wrote:
Words is (non-)wisdom(tm): Many wearleveling optimisations from the linux side will not (fully) work with encrypted fs or encrypted partitions, e.g. TRIM. Hint 1: Go for a drive with a high TBW / drive-writes count. Hint 2: overprovisioning (leaving free non-partitioned space) helps. Hint 3: Warranty: 10 years cost (extra) money, 5 years is good sense, 3 years is (very) low. It could be that a MLC drive wins out against TLC one. Further Info startpoint: https://en.wikipedia.org/wiki/Flash_memory#Write_endurance https://en.wikipedia.org/wiki/Multi-level_cell https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning Do not go below 240 GB, as the value per money is (much) worse below that. In the enterprise (datacenter) class I've had little to no problem with the Samsung and Intel drives of the last 3 years, but time will tell - as warranty begins to run out on some of them now. Early Intel was uneven. In the professional (desktop/soho-server) class (10 years warranty), well, no drop out on any drives mounted since 2012, but, see above, time will tell, all on warranty still. In the semi-pro (desktop/soho-server) class (5 years warranty), about 5 per 1000 dropout rate before end-of-warranty (time or TBW reached), seams to be spread all over the manufactureres and the products. In the (IMHO) home-use-only class (less than 5 years warranty, less than 60 Drives-writes TBW), it's a very mixed bag, some charges are very good, but the ones before and after could be crap (same manufacturer, same product). *shrugs* You get wat you pay for. 20 bucks more for a drive with 5 years instead of a 3 year warranty is simply good sense and better sleep. About the same as the tires on your car. - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/02/2016 05:03 PM, Yamaban wrote:
I might just use the drive's own encryption capabilities and abandon luks.
I also saw this: http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-d... He says that all these drives exceed their stated longevity by astounding amounts. Thanks... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/02/2016 05:03 PM, Yamaban wrote:
Hint 2: overprovisioning (leaving free non-partitioned space) helps.
Yamaban... Can you elaborate on this? Wouldn't wear leveling still respect partition boundaries, and unallocated space be ignored? Aren't there enough free-replacement blocks to handle any bad spots that develop? What purpose does unallocated space serve? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Nov 4, 2016 at 6:45 PM, John Andersen <jsamyth@gmail.com> wrote:
John, I don't know if modern SSDs still need that treatment. They may all inherently be over-provisioned? == assuming they aren't You seem to be missing the basics of how a SSD works. There is not a rigid mapping of logical sector addresses to physical storage like there is with a HDD. It's all extremely dynamic and the mapping is updated on every single data write. Not just on bad-spot replacement like on a HDD. There is a queue of unused EBs (erase blocks) that get pulled from on every single data write. Even an update of an already allocated data block causes a new, blank EB to be allocated from the queue for the new data, and the formerly used EB is moved to the back of the queue. It takes several milliseconds for that no-longer useful EB to be erased, so the queue has to be deep enough that that EB isn't needed for some milliseconds. There is NOT an unused EB queue per partition, only one per SSD. If a non-encrypted filesystem is used, the SSD can be told which data blocks are empty and it adds those to the queue of available EBs. Basically for unallocated data blocks, there is no backing store. Thus the EB queue for a SSD with a normal 50% filesystem will have approximately 50% of the EBs in the unused EB queue. SSDs work optimally when the unused EB queue is relatively large. If that queue gets too small, the SSD slows down significantly on writes of any kind. If you are using an encrypted FS, then the SSD doesn't know which data blocks have valid data. Thus every data block has to have an actual backing store and the unused EB queue will be very small. If you over-provision by leaving unallocated partition space, the SSD will leave those data blocks with no backing store and all of those EBs will be kept in the unused EB queue. Hope that helps, Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/04/2016 04:08 PM, Greg Freemyer wrote:
If you are using an encrypted FS, then the SSD doesn't know which data blocks have valid data.
Does this only apply only to something like luks, (operating system crypto)? Or does it also apply to whole drive encryption built into many of these devices? (Most claim no performance degradation using their built in enctryption) (Note that I am dealing with a laptop here so I'm leaning towardd something like these. https://www.amazon.com/dp/B00OBRE5UE/ref=psdc_1292116011_t1_B00LF10KTO or https://www.amazon.com/dp/B00LF10KTO/ref=psdc_1292116011_t3_B00OBRE5UE Thks for info. It confirms my prior understandings.... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Donnerstag, 3. November 2016, 01:03:49 schrieb Yamaban:
TRIM does work with DMCrypt since Kernel 3.1. But there are theoretical security implications: https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt | allow_discards: Allow block discard requests (a.k.a. TRIM) for the crypt device. | The default is to ignore discard requests. | Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later. | Available since: 1.11.0 (kernel 3.1) man crypttab (Leap 42.1) | discard | Allow discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. About hardware full disk encryption (FDE): http://security.stackexchange.com/questions/134564/how-secure-is-hardware-fu... IMHO using hardware FDE is better than nothing and will prevent a common thief from reading the disk of your laptop. Gruß Jan -- He who hesitates is sometimes saved. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Nov 2, 2016 at 7:18 PM, John Andersen <jsamyth@gmail.com> wrote:
Technologies? is a better question. For a lightly loaded PC, most any AHCI SSD will do great. I've mostly been buying Samsung SSDs with a SATA interface. For a state of the art experience that can handle a multi-threaded load like a server can throw at it, you want a NVMe SSD. Those don't have SATA ports, they are made to run at native PCIe speeds. Meaning fast as hell. Here's a year old article about one that was just released back then: http://arstechnica.com/gadgets/2015/10/950-pro-review-samsungs-first-pcie-m-... I have a Asus X.99 Deluxe MB that has a NVMe SSD connector directly on the MB. The SSD plugs into that vertically. (Unlike the picture in the article where the SSD is laying flat.) I have a Samsung PM951 (MZ-VLV1280) 128GB (I bought it to test functionality with, so the cheapest I could find.) I've been running Leap 42.2 (beta => RC1) on that pair since I bought the SSD (in June I think). I have had zero issues with doing so, but I mostly tinker with that machine, so I don't have any meaningful benchmarks. One new thing to learn is the drive is NOT /dev/sda It is /dev/nvme* nvme => Non-Volatile Memory Express nvme0 => The first NVMe SSD nvme0n1 => the first namespace of the first NVMe SSD nvme0n1p1 => The first partition on the first namespace of the NVMe SSD If your MB (like most) doesn't have a connector, you can buy a PCIe adapter for $25 or so dollars. Here's one example: https://www.amazon.com/Ableconn-PEXM2-SSD-NGFF-Express-Adapter/dp/B017JGVTAM... I haven't used an adapter, so no pros/cons from me. I assume they work with older MBs and CPUs. Alright, a quick performance test with my hardware. I was doing some 32-bit openSUSE 13.1 compatibility testing, so I openSUSE 13.1 boot CD booted at the moment. I did: time dd if=/dev/nvme0n1 of=/dev/zero bs=1M count=10000 It took 15.5 seconds to read 10GB., or 675 MB/sec. Again, that's with a 3-year old 32-bit kernel. Booting back to 64-bit Leap 42.2 RC1 9.8 seconds, or 1.1 GB/sec I'm actually surprised the 64-bit speed is that low. HTH Greg Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 02 Nov 2016 04:18:35 PM CDT, John Andersen wrote:
Hi I purchased a SanDisk Extreme Pro SSD 240GB recently; http://www.anandtech.com/show/8170/sandisk-extreme-pro-240gb-480gb-960gb-rev... I have three OCZ's (60 and 120GB) and a Crucial 120GB have many K's of hours now and all running fine. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.34-33-default up 4 days 7:54, 4 users, load average: 0.71, 0.40, 0.28 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 03 Nov 2016, John Andersen wrote:
I'm running Leap 42.2 (RC1) with a SATA Samsung SSD 850 EVO 250GB (AMD Phenom II X6 1090T, 8GB, Nvidia GTX 650 Ti, Seagate ST2000DM001). I'm using ext4 for root (I briefly toyed with btrfs, but backing up it's sub-partition structure proved difficult to retrofit to my simple rsync based backup regime). Btrfs is supposed to better support SSD's (but I gather its not a big deal). I did a fresh install of 42.2 (RC1) and re-applied all my usual settings and packages. It all went smoothly. There seems to be some confusion on the web about Samsung and trim support. My dmesg output contains: [ 3.267504] ata1.00: disabling queued TRIM support [ 3.267511] ata1.00: ATA-9: Samsung SSD 850 EVO 250GB, EMT02B6Q, max UDMA/133 I think this is mainly for older drives, which mine is not. I've decided not to worry about it. I may look into using fstrim (man 8 fstrim) but I'm not sure whether this too might be an issue. The 42.2 kernel build seems to have correctly picked to use the deadline scheduler for the SSD (only): cat /sys/block/sda/queue/scheduler noop [deadline] cfq I decided to put noatime in mount entry in /etc/fstab to reduce writes (some say this is no longer really necessary). My previous OCZ SSD died after 5 years. I've read that SSD's can fail without warning. In my case, the OS just started errorring like crazy and crashed. There was no possibility of recovering anything as the failed drive was no longer recognised. So it would be a good idea to keep backups on other media. I backup the OS to both online and offline hard drives, so I lose a day to a week depending. My SSD failed just after installing Tumbleweed in a spare partition, so perhaps all the new activity pushed the writes over some limit. I still keep /home on a hard drive - being into photography makes SSD to expensive for user space. Cheers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/11/2016 à 00:18, John Andersen a écrit :
don't worry. Take any ssd you can afford (obviously the more expensive may be marginally better). On Leap 42.1 I don't trust BTRFS anymore (if I can't manage a more than 100Gb /) and use ext4. on Leap 42.2 I may try BTRFS and 3 years waranty is enough: you probably wont keep the disk that long. I already have on my drawer a 128 Gb and a 250 Gb ssd, because I now use a 500Gb one... The ssd technology is making better and cheaper so fast... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Carlos E. R. -
Dave Howorth -
Greg Freemyer -
James PEARSON -
Jan Ritzerfeld -
jdd -
John Andersen -
Malcolm -
Michael Hamilton -
Yamaban