Computex : WD agrandit son portfolio de SSD externes
▻https://www.tomshardware.fr/articles/western-digital-ssd-externe-gdrive,1-67702.html#xtor=RSS-5
Le roi du RAID.
▻https://img.purch.com/rc/120x90/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9WLzYvNzc3NDI2L29yaWdpbmFsL0lNR18yM
Cartes mères AMD X399 : RAID bootable de NVMe grâce à de nouveaux pilotes
▻http://www.tomshardware.fr/articles/x399-raid-amd-threadripper,1-65241.html#xtor=RSS-100
Problème résolu
AMD Threadripper : chipset X399 incompatible avec un RAID NVMe bootable
▻http://www.tomshardware.fr/articles/threadripper-amd-processeur-carte-mere,1-64983.html#xtor=RSS-100
Un frein au succès des Threadripper ?
Il me semblait avoir vu passer sur seenthis, mais je ne retrouve pas
▻https://en.wikipedia.org/wiki/AltaVista#Origins
Email from early January, 1996:
...
Alta Vista is a very large project, requiring the cooperation of at
least 5 servers, configured for searching huge indices and handling
a huge Internet traffic load. The initial hardware configuration
for Alta Vista is as follows:
Alta Vista — AlphaStation 250 4/266
4 GB disk
196 MB memory
Primary web server for gotcha.com
Queries directed to WebIndexer or NewsIndexer
NewsServer — AlphaStation 400 4/233
24 GB of RAID disks
160 MB memory
News spool from which news index is generated
Serves articles (via http) to those without news server
NewsIndexer — AlphaStation 250 4/266
13 GB disk
196 MB memory
Builds news index using articles from NewsServer
Answers news index queries from Alta Vista
Spider — DEC 3000 Model 900 (replacement for Model 500)
30 GB of RAID disk
1GB memory
Collects pages from the web for WebIndexer
WebIndexer — Alpha Server 8400 5/300
210 GB RAID disk (expandable)
4 GB memory (expandable)
4 processors (expandable)
Builds the web index using pages sent by Spider.
Answers web index queries from Alta Vista
Make the best of SSD+HDD in terms of storage and performance alltogether
- The problem: An SSD + HDD system can’t go faster than the slowest drive for every HDD (mostly data related) operations.
- A solution: Allows for one or more solid-state drives (SSDs) to act as a cache for slower rotational hard disk drives.
Some more details:
Think like this: you want to have a 4TB array, SSD of such size will set you back at least $10000, HDD RAID of similar size will cost you less than $500, even at RAID10 redundancy.
Problem is, that ’find’, or ’updatedb’ will easily take more than 10 minutes if you have large files (in the 100MB range) or few dozen minutes if you have smaller files on HDDs and at most a minute with the SSD.
Now, the only thing that needs to be read from such an array is metadata, which in itself is small, less than 1%.
If you could put only metadata on a SSD you’d get a disk just as fast in such workloads as the $10000 array for a fraction of the price.
In most small to medium businesses and home media servers you don’t need thousands of IOPS (which big database and large www servers need - that’s why SSD exclusive storage has its place), at the same time you want to have access to your most used files be fast (Windows roaming profiles, DE configuration files), and don’t have to manually move it between fast and slow storage.
Some references:
- ▻http://www.linux.com/learn/tutorials/754674-using-bcache-to-soup-up-your-sata-drives
SSDs are super fast but can be cost-prohibitive [while it’s the opposite for HDD]. With the help of bcache, you can use a smaller SSD as a caching drive for the larger, slower HDD. With this set up, you have the best of both worlds.
- A lightning fast SSD housing your operating system.
- A bcache-enabled SSD that caches for your large HDD data drive.
As of kernel 3.10, bcache is available with minimal installation and work.
Warning: Although you can set this up on an existing system (with existing data), I highly recommend you not do so.
Or check out g2p’s blocks, a conversion tool that enable bcache or LVM on existing block devices without moving data: ▻https://github.com/g2p/blocks
En Fr: Matériel : Accéleration disques durs via SSD sous Linux : les technos existantes (10/2012) ▻http://linuxfr.org/news/acceleration-ssd-sous-linux
Bcache For The Linux Kernel Might Finally Be Ready ▻http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDg
An alternative to Bcache: SSD, LVM, Tiered storage - speeding up your storage - alpha version! ▻https://bbs.archlinux.org/viewtopic.php?id=113529
In my tests I saw some bottlenecks in LVM that made it impossible to achieve more than 300% gains (pure SSD setup was over 10 times faster) with mixed setup (HDD+SSD).
Commentaires et retours d’expérience bienvindus ;)
What to do with uselessly insecure #cloud #storage services ? Use them as redundant backends for #Tahoe-LAFS ! Introduction at ►http://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bunch-of-independent-clouds and code at ▻https://github.com/mk-fg/tahoe-lafs-public-clouds #RAID #security
How multi-disk failures happen
►http://sysadmin1138.net/mt/blog/2012/12/how-multi-disk-failures-happen.shtml
Having seen this failure mode happen a couple times now, it’s time to share. Yes, Virgil, multi-disk failures DO happen during RAID rebuilds. I have pictures, so it MUST be true!First, let’s take a group of disks …
Source: Sysadmin1138
Introducing BRIC (Bunch of Redundant Independent Clouds) « Bitcartel Blog
►http://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bunch-of-independent-clouds
Online storage providers are handing out free storage like candy. Add them all up and soon you’re talking about a serious amount of space. So let’s have some fun by turning ten different online storage providers into a single data grid which is secure, robust, and distributed. We call this grid a BRIC (Bunch of Redundant Independent Clouds).
The BRIC solution presented here will use the open source project Tahoe-LAFS to perform the RAID like function of striping data across different storage providers. Here’s how Tahoe-LAFS describes itself:
Tahoe-LAFS is a Free and Open cloud storage system. It distributes your data across multiple servers. Even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to function correctly, including preservation of your privacy and security.
Solution de backup utilisant ►https://tahoe-lafs.org/trac/tahoe-lafs