Re: "best practices" for using a small SSD boot drive and a big regular one?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/14/2012 12:56 PM, Reindl Harald wrote:
>> If your rotating disk will always be connected, you may want to have
>> a unique VG across both the SSD and the HD, so you can move partitions
>> across them and have more flexibility.
>> For example, if you realize to need some more space on a SSD filesystem,
>> you still have to ability to enlarge the partition into the HD and cope with
>> a partially-here/partially-there layout.
>> This road can lead to very interesting tricks, such as having the
>> journal and metadata on SSD and actual data on HD.
> 
> and what happens if ONE drive fails?

Maybe restore from backup?
Backups on Linux are trivial: external drive + rsync/rsnapshot.

Not having a backup is a risk even with only one drive.
HDs fail, SSDs fail, laptop are dropped/lost/stolen.

Protecting your data doesn't imply you have to run away
from RAID-0 in panic.

> colume groups over different drives are a VERY bad idea
> as long LVM does not sit on top of a RAID!
> 
> having as example a LVM over 3 drives makes it 3 times
> more possible to lose the whole volume groups data
> if one drive goes down

Yes.
A 500,000 hours MTBF is 114 years of usage (at 12 hours per day).
Three similar drives in RAID-0 is 38 years of usage (at 12h/day).

> this is the same as for RAID0: do it only if it does
> not bother you losing your data!

Don't be so dogmatic.
Just estimate the risk and take countermeasures.

As regards my future SSD+HD project that I cited before, be assured
that I'm using 2 RAID1 SSDs and 8 RAID10 HDs.
Plus rsync backups every 4 hours.
Plus daily remote backup.
But this is a production server. On a laptop you can't do that;
the laptop is so easily damaged/lost that your data should be
backupped anyway just for that; at that point why not play with
some smart disk arrangement to make it work faster?

-- 
   Roberto Ragusa    mail at robertoragusa.it


-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux