[opensuse] Are PCI-E SSD Cards Supported?
Hi, Not knowing how much or little overlap there is between the openSUSE Forums and this list, I am posting my question from there [1] here, as well: -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- I am considering an OCZ RevoDrive SSD that takes the form of a PCI-Express x4 card. I have not been able to find compatibility or support information for Linux, though apparently it works OK under Windows 7. I want to make this a system / boot drive. Any information, especially direct experience, would be welcome. -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- [1] <http://forums.opensuse.org/english/get-technical-help-here/hardware/461345-pci-e-ssd-cards-supported.html> Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
Hi,
Not knowing how much or little overlap there is between the openSUSE Forums and this list,
Zero overlap to my knowledge. -- Per Jessen, Zürich (13.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 11 June 2011 21:46:48 Randall R Schulz wrote:
I am considering an OCZ RevoDrive SSD that takes the form of a PCI-Express x4 card. I have not been able to find compatibility or support information for Linux, though apparently it works OK under Windows 7.
I want to make this a system / boot drive.
Any information, especially direct experience, would be welcome.
No direct experience I'm afraid, I'm staying away from SSDs until they become big enough to warrant my attention, but here is a review that says they tested on Ubuntu 10.10 with no issues, which should mean it works in openSUSE 11.4 as well http://www.overclockersclub.com/reviews/ocz_revodrive_50gb/ Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday June 11 2011, Anders Johansson wrote:
On Saturday 11 June 2011 21:46:48 Randall R Schulz wrote:
I am considering an OCZ RevoDrive SSD that takes the form of a PCI-Express x4 card. I have not been able to find compatibility or support information for Linux, though apparently it works OK under Windows 7.
I want to make this a system / boot drive.
Any information, especially direct experience, would be welcome.
No direct experience I'm afraid, I'm staying away from SSDs until they become big enough to warrant my attention, but here is a review that says they tested on Ubuntu 10.10 with no issues, which should mean it works in openSUSE 11.4 as well
http://www.overclockersclub.com/reviews/ocz_revodrive_50gb/
Anders
The board I'm looking at is a 120 GB drive. Plenty for a system install. I'm trying to go for tiered storage, so I want the SSD as the system drive, a 10,000 RPM, 600 GB VelociRaptor (SATA III / 6 Gbps) in the box with a gigabit Ethernet-connected NAS with 8 TB RAID 5 (5.5 TB available) as my near-line storage. Feedback and better ideas are welcome. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz said the following on 06/11/2011 04:22 PM:
On Saturday June 11 2011, Anders Johansson wrote:
On Saturday 11 June 2011 21:46:48 Randall R Schulz wrote:
I am considering an OCZ RevoDrive SSD that takes the form of a PCI-Express x4 card. I have not been able to find compatibility or support information for Linux, though apparently it works OK under Windows 7.
I want to make this a system / boot drive.
Any information, especially direct experience, would be welcome.
No direct experience I'm afraid, I'm staying away from SSDs until they become big enough to warrant my attention, but here is a review that says they tested on Ubuntu 10.10 with no issues, which should mean it works in openSUSE 11.4 as well
http://www.overclockersclub.com/reviews/ocz_revodrive_50gb/
Anders
The board I'm looking at is a 120 GB drive. Plenty for a system install.
I'm trying to go for tiered storage, so I want the SSD as the system drive, a 10,000 RPM, 600 GB VelociRaptor (SATA III / 6 Gbps) in the box with a gigabit Ethernet-connected NAS with 8 TB RAID 5 (5.5 TB available) as my near-line storage.
Feedback and better ideas are welcome.
I'm not sure what you mean by 'tiered', Randall, but I will observe that I have 11.4 running on an old laptop with a 60G drive. That includes the user space: documents, PDFs, music, video. So I think a 'system' could fit on a lot less than that! I'd bank for 40G. It depends on what you call 'system'. There is a lot of /sbin that doesn't get used much; the same goes for /lib, /usr/[s]bin and /usr/lib -- and the subdirectories of /usr/lib. But it all depends... "Context is Everything" ... as I keep saying. Is this a desktop or a server? What applications? My view is that there are things like _some_ fonts and _some_ icons/graphics that get used heavily, so perhaps parts of /usr/ and /usr/share need to be on fast access (but only parts!). Or are things like this cached? Globally or a per-user basis? The way I see it we need to implement an overlay file system. There is a /usr/bin and /usr/lib on the SSD that overlays the fully populated version on the hard drive, and _somehow_ (!*!*!) the most used items get migrated up onto the SSD. SOMEHOW. If the "somehow" is smart, then creating a directory on the SSD enables the migration for that ... so we can easily add /usr/share/fonts. Then again, my ~/.kde4/cache-${HOSTNAME} is on /var/tmp/kdecache-anton and /var/tmp is vartmp on /var/tmp type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1048576k) so perhaps having swap on the SSD would help too. What? No Swap? Perhaps. For some reason I see tmpfs using swap on a system that doesn't have enough going on to want to use swap for processes. My view is like this: 1. SSD is still expensive and will continue to be for some time, and probably will always be more so than hard drives. 2. Use the space on the SSD as efficiently and effectively as possible That is; don't use it for things that won't be used. This leads to it acting like a cache for the most used items rather than for the whole of the "system". This leads to a secondary problem: what happens when you run and update or patch? -- Fiction is a noble pursuit. Ideally, it profoundly changes the ways in which people perceive their experience. --Norman Mailer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anton Aylward wrote:
There is a lot of /sbin that doesn't get used much; the same goes for /lib, /usr/[s]bin and /usr/lib -- and the subdirectories of /usr/lib. But it all depends... "Context is Everything" ... as I keep saying. Is this a desktop or a server? What applications?
My view is that there are things like _some_ fonts and _some_ icons/graphics that get used heavily, so perhaps parts of /usr/ and /usr/share need to be on fast access (but only parts!). Or are things like this cached? Globally or a per-user basis?
All files are cached, globally.
The way I see it we need to implement an overlay file system. There is a /usr/bin and /usr/lib on the SSD that overlays the fully populated version on the hard drive, and _somehow_ (!*!*!) the most used items get migrated up onto the SSD. SOMEHOW.
unionfs? -- Per Jessen, Zürich (22.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen said the following on 06/12/2011 10:14 AM:
Anton Aylward wrote:
There is a lot of /sbin that doesn't get used much; the same goes for /lib, /usr/[s]bin and /usr/lib -- and the subdirectories of /usr/lib. But it all depends... "Context is Everything" ... as I keep saying. Is this a desktop or a server? What applications?
My view is that there are things like _some_ fonts and _some_ icons/graphics that get used heavily, so perhaps parts of /usr/ and /usr/share need to be on fast access (but only parts!). Or are things like this cached? Globally or a per-user basis?
All files are cached, globally.
Yes, I understand about the page-cache, LRU and all that and "load on demand" nature of the file mapping of binaries. But if that is so good why do we have ~/.cache and ... ~/.fonts.cache ~/.libreoffice/3-suse/user/store/.templdir.cache ~/.xdg_menu_cache ~/.local/share/mime/mime.cache ~/.mozilla/firefox/o7k1u7k5.default/extensions.cache ~/.java/deployment/cache Lots more under ~/.kde4/share/apps/
The way I see it we need to implement an overlay file system. There is a /usr/bin and /usr/lib on the SSD that overlays the fully populated version on the hard drive, and _somehow_ (!*!*!) the most used items get migrated up onto the SSD. SOMEHOW.
unionfs?
Yes, that implements the overlay. the SSD has priority over the hard drive. But the question remains: how to the most used items get migrated to the SSD? We can speculate as to what is most used, and I'm sure in the case of /bin/sh and some things like kdeinit4, kwin and others determined from 'fuser' and 'lsof' we'd be correct. But then what? And as I said, how to deal with updates. Does unionfs support some kind of write-though? -- "The man who does not read good books has no advantage over the man who can't read them." --Mark Twain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/12/2011 10:14 AM:
Anton Aylward wrote:
There is a lot of /sbin that doesn't get used much; the same goes for /lib, /usr/[s]bin and /usr/lib -- and the subdirectories of /usr/lib. But it all depends... "Context is Everything" ... as I keep saying. Is this a desktop or a server? What applications?
My view is that there are things like _some_ fonts and _some_ icons/graphics that get used heavily, so perhaps parts of /usr/ and /usr/share need to be on fast access (but only parts!). Or are things like this cached? Globally or a per-user basis?
All files are cached, globally.
Yes, I understand about the page-cache, LRU and all that and "load on demand" nature of the file mapping of binaries.
But if that is so good why do we have ~/.cache and ... ~/.fonts.cache ~/.libreoffice/3-suse/user/store/.templdir.cache ~/.xdg_menu_cache ~/.local/share/mime/mime.cache ~/.mozilla/firefox/o7k1u7k5.default/extensions.cache ~/.java/deployment/cache Lots more under ~/.kde4/share/apps/
Just a guess - they're holding user/application specific data, perhaps only valid for a current session.
The way I see it we need to implement an overlay file system. There is a /usr/bin and /usr/lib on the SSD that overlays the fully populated version on the hard drive, and _somehow_ (!*!*!) the most used items get migrated up onto the SSD. SOMEHOW.
unionfs?
Yes, that implements the overlay. the SSD has priority over the hard drive.
But the question remains: how to the most used items get migrated to the SSD?
Essentially it's just another layer in the cache hierarchy, so the algorithm is probably the same. Everytime a file is read from drive2, it is copied to drive1, next time it will be picked up from drive1. Whenever a file is written to, it it is copied back to drive2. To keep the SSD-cache from overflowing, you purge files by LRU.
And as I said, how to deal with updates. Does unionfs support some kind of write-though?
I think you could probably do this _relatively_ easy with a user-space filesystem. There is already a unionfs implemented as FUSE. -- Per Jessen, Zürich (15.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen said the following on 06/13/2011 03:47 AM:
All files are cached, globally.
Yes, I understand about the page-cache, LRU and all that and "load on demand" nature of the file mapping of binaries.
But if that is so good why do we have ~/.cache and ... ~/.fonts.cache ~/.libreoffice/3-suse/user/store/.templdir.cache ~/.xdg_menu_cache ~/.local/share/mime/mime.cache ~/.mozilla/firefox/o7k1u7k5.default/extensions.cache ~/.java/deployment/cache Lots more under ~/.kde4/share/apps
Just a guess - they're holding user/application specific data, perhaps only valid for a current session.
I don't think so, not in all cases. The reason I think this is because there is a per-session cache under /usr/tmp/kdecache-anton/ There's also /usr/tmp/kdecache-kdm/ YMMV if you use Gnome. I have no doubt that the various caches I mentioned previous are _updated_ or rebuilt (if required) each session. But if they are holding session-specific data then WHY? Why not keep it in mapped/paged memory? If it is a per session cache for the application and needs retrieval, then its a candidate for fast storage, isn't it? Which get back to my original point. -- It is the first step of wisdom to recognize that the major advances in civilization are processes which all but wreck the society in which they occur. --Alfred North Whitehead -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/13/2011 03:47 AM:
All files are cached, globally.
Yes, I understand about the page-cache, LRU and all that and "load on demand" nature of the file mapping of binaries.
But if that is so good why do we have ~/.cache and ... ~/.fonts.cache ~/.libreoffice/3-suse/user/store/.templdir.cache ~/.xdg_menu_cache ~/.local/share/mime/mime.cache ~/.mozilla/firefox/o7k1u7k5.default/extensions.cache ~/.java/deployment/cache Lots more under ~/.kde4/share/apps
Just a guess - they're holding user/application specific data, perhaps only valid for a current session.
I don't think so, not in all cases. The reason I think this is because there is a per-session cache under /usr/tmp/kdecache-anton/ There's also /usr/tmp/kdecache-kdm/
YMMV if you use Gnome.
I have no doubt that the various caches I mentioned previous are _updated_ or rebuilt (if required) each session.
But if they are holding session-specific data then WHY? Why not keep it in mapped/paged memory?
More wild guessing - because it needs survive a crash?
If it is a per session cache for the application and needs retrieval, then its a candidate for fast storage, isn't it?
Perhaps - but it's already cached by the filesystem buffers. -- Per Jessen, Zürich (20.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen said the following on 06/13/2011 08:08 AM:
But if they are holding session-specific data then WHY? Why not keep it in mapped/paged memory?
More wild guessing - because it needs survive a crash?
Possibly. In some cases. But not all, surely?
If it is a per session cache for the application and needs retrieval, then its a candidate for fast storage, isn't it?
Perhaps - but it's already cached by the filesystem buffers.
Which gets back to my original question ... And of course the general cure to Linux performance issues: throw more memory at it! Sadly there is a lower limit with laptops and netbooks than with desktops and servers. -- Security is old, older than computers And old-guard security thinks of countermeasures as a way to manage risk. Avoiding threat is black & white, either you avoid it or you don't. Managing risk is continuous. - B Schneier, "Secrets and Lies" pp 385 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 06/13/2011 08:08 AM:
But if they are holding session-specific data then WHY? Why not keep it in mapped/paged memory?
More wild guessing - because it needs survive a crash?
Possibly. In some cases. But not all, surely?
I think the only/main reasons for keeping something in a file is to make the contents persistent and/or to reduce memory usage.
If it is a per session cache for the application and needs retrieval, then its a candidate for fast storage, isn't it?
Perhaps - but it's already cached by the filesystem buffers.
Which gets back to my original question ... And of course the general cure to Linux performance issues: throw more memory at it!
Sadly there is a lower limit with laptops and netbooks than with desktops and servers.
Right, and ssd storage is cheaper than RAM sticks. Mind you, I bought two new Toshiba laptops about a month ago. 3Gb memory. -- Per Jessen, Zürich (20.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen said the following on 06/13/2011 08:45 AM:
Which gets back to my original question ... And of course the general cure to Linux performance issues: throw more memory at it!
Sadly there is a lower limit with laptops and netbooks than with desktops and servers.
Right, and ssd storage is cheaper than RAM sticks. Mind you, I bought two new Toshiba laptops about a month ago. 3Gb memory.
My Compaq X6000 of 2005 vintage has 2Gb I see laptops with 6Gb or even 8Gb if you're willing to pay, http://reviews.cnet.com/laptop-reviews/?filter=500053_15242097_ but laptops are closed boxes with a very, very limited hardware upgrade path compared to the open chassis of desktops. I can throw 16Gb at the old "desktop class" machine under my desk (but wonder why a mailhub would need that); there are plenty of motherboards that support 128Gb or 256Gb. Just not for laptops :-( -- Never tell people how to do things. Tell them what you want them to achieve, and they will surprise you with their ingenuity. --George Patton -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 12 June 2011 10:47:14 Anton Aylward wrote:
Yes, I understand about the page-cache, LRU and all that and "load on demand" nature of the file mapping of binaries.
But if that is so good why do we have ~/.cache and ... ~/.fonts.cache ~/.libreoffice/3-suse/user/store/.templdir.cache ~/.xdg_menu_cache ~/.local/share/mime/mime.cache ~/.mozilla/firefox/o7k1u7k5.default/extensions.cache ~/.java/deployment/cache Lots more under ~/.kde4/share/apps/
They solve a different kind of problem. Page caching means you don't have to read as much or as often from disk, and cache files like those mean you don't have to recalculate things every time. They are typically precalculated, pre- selected data, so it only has to be done once Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Jun 11, 2011 at 4:08 PM, Anders Johansson <ajh@nitio.de> wrote:
On Saturday 11 June 2011 21:46:48 Randall R Schulz wrote:
I am considering an OCZ RevoDrive SSD that takes the form of a PCI-Express x4 card. I have not been able to find compatibility or support information for Linux, though apparently it works OK under Windows 7.
I want to make this a system / boot drive.
Any information, especially direct experience, would be welcome.
No direct experience I'm afraid, I'm staying away from SSDs until they become big enough to warrant my attention, but here is a review that says they tested on Ubuntu 10.10 with no issues, which should mean it works in openSUSE 11.4 as well
http://www.overclockersclub.com/reviews/ocz_revodrive_50gb/
Anders
I'm highly intriqued with SSD and follow them closely, but anecdotally they seem to have a very short MTBF. (Mean Time Between Failures.) Everyone I personally know that has bought one has had it die in the first year. I hope the reality is better than my perception. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2011/06/11 23:30 (GMT-0400) Greg Freemyer composed:
I'm highly intriqued with SSD and follow them closely, but anecdotally they seem to have a very short MTBF. (Mean Time Between Failures.)
Everyone I personally know that has bought one has had it die in the first year.
I hope the reality is better than my perception.
A friend brought me a 19 month old Dell Inspiron 910 netbook only a few days ago to try to "fix". I have no means at immediate disposal to confirm, but it appears its "only" problem is its only (smaller than a laptop DIMM) storage medium is dead, a STEC 080819-P03-001 DEL00-01850-M3BCU, with size and apparent socket type matching its wireless card. :-p -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
El 11/06/11 15:46, Randall R Schulz escribió:
Hi,
Not knowing how much or little overlap there is between the openSUSE Forums and this list, I am posting my question from there [1] here, as well:
This shouldn't be a problem at all. just ensure your BIOS is capable of booting from PCI express.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday June 11 2011, Cristian Rodríguez wrote:
El 11/06/11 15:46, Randall R Schulz escribió:
Hi,
Not knowing how much or little overlap there is between the openSUSE Forums and this list, I am posting my question from there [1] here, as well:
This shouldn't be a problem at all. just ensure your BIOS is capable of booting from PCI express..
Great, thanks. Now that I think of it, I boot from my PCI-E SCSI controller all the time (though this will be a new motherboard, I'd be shocked, appalled and returning it if it couldn't boot from those devices). I shouldn't have really thought SSD was such a horse-of-another-color from a system integration perspective. Anyway, some further research is leading me toward an Intel SSD anyway and as far as I know, they don't do PCI-E boards for their SSD devices. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
El 11/06/11 17:39, Randall R Schulz escribió:
Anyway, some further research is leading me toward an Intel SSD anyway and as far as I know, they don't do PCI-E boards for their SSD devices.
I have one, 80GB X25-M 2d gen. Works wonderful, except for one already fixed glitch when used with smartd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Is there any reason you don't use SATA SSD? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday June 12 2011, Andrew Joakimsen wrote:
Is there any reason you don't use SATA SSD?
The need for speed and the desire to avoid setting up my own internal RAID 0 array, which from what I can tell is the only way to match the RevoDrive x2's performance. I'm building what I hope will qualify (for a few months, anyway) as a fast desktop machine. It's a Sandy Bridge system with an i7 2600K CPU, the P67 chipset on an ASUS P8P67 EVO board with 16 GB of 1600 MHz DDR3 DRAM, the RevoDrive x2 SSD and a 600 GB VelociRaptor (10,000 RPM SATA III). I haven't picked the graphics hardware, yet. I'm going to swap in the video card from the system its replacing for the time being. By the way, up 'til now, I've used SCSI drives, first Ultra 160 and in my latest system, Ultra 320 15,000 RPM drives (which are none to capacious and rather expensive, too). Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2011-06-12 at 05:21 -0400, Andrew Joakimsen wrote:
Is there any reason you don't use SATA SSD?
I'll guess the need-for-speed. it is pci-bus-speed compared to ata-speed. For the same reason we got some fusion-io SSD hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
El 12/06/11 17:19, Hans Witvliet escribió:
For the same reason we got some fusion-io SSD
Well,that's an alternative for business, but not really for end users, It is a quite expensive piece of hardware. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (9)
-
Anders Johansson -
Andrew Joakimsen -
Anton Aylward -
Cristian Rodríguez -
Felix Miata -
Greg Freemyer -
Hans Witvliet -
Per Jessen -
Randall R Schulz