Talk:AddExtraHardDisk
All the talk belwo looks to be no longer relevant, I propose to delete it Terry Fage (talk) 04:46, 15 February 2013 (MST)
1. It might be useful to make a shorter, more printer-friendly version. Maybe as pdf?
2. Another suggestion is to replace the names bigdisk, mp3 and hdc1 with variables that the user can change to fit their situation.
These variables will then change the later paths automatically.
I think that would increase the success-rate when using it.
3. Maybe combine suggestion 1 and 2, so the printable version show the customized paths? Would that be doable? How?
4. Is it really necessary to go to runlevel 1 (with telinit 1)?
It's a petty that I can't do these actions thru an ssh-client (copy and paste-ability).
Doesn't the CONSOLE > MANAGE DISK REDUNDANCY already take care of this automatically? If so, I don't know why this HOWTO is needed. http://wiki.contribs.org/Raid#Adding_another_Hard_Drive_Later
Another Option
Not recommended way as if you loose the drive you loose your system but you are in a world of hurt following these instructions and loose the drive as well. In all of these commands you would replace {drive} with the device you are working with (hda,hdc,sda,sdb,etc).
fdisk /dev/{drive}
Do the n,p,1 stuff. Then do T (change partition type), 1 (partition 1), 8e (Linux LVM). You can then write and save the partion.
Instead of formatting the drive do the following:
pvcreate /dev/{drive}1
The 1 at the end specifies the partition you created in fdisk.
Add the new partition to the volume group with:
vgextend main /dev/{drive}1
And check that you have new available space (it should show total size and free space):
vgs
Increase the root logical volume with:
lvresize -L +{space available} main/root
And finally increase the filesystem with:
ext2online -C0 /dev/main/root
Also see Upgrading the Hard Drive Size in the Raid article. The lvresize and ext2online commands can be used to take advantage of all of the available space.
By following these instructions you aren't just limiting space to a specific mount point/ibay but make it available to the entire system. You also don't have to mess with or tweak quotas. The space just becomes available.
If you are using a clean drive that is new to the system you shouldn't have to reboot or telinit 1 either.
I am in favor of above solution as this is much easier for users, how about replacing the original article or adding it as a separate article in the WIKI? - Cactus 15:41, 18 August 2007 (MDT)
- Go for it. I'm not great at putting things down, especially in the wiki. I'll fill in anything that you need just ask. I'd also be good for someone else to run through the steps and ensure they are accurate and re-document what they did. — Slords (talk • contribs). 16:10, 18 August 2007 (MDT)
- I'd hope most people are using raid, for safety in case a disk fails.
This howto is for adding another disk just for storage, if it is mounted as an ibay users should be able to appreciate it is vulnerable and backup accordingly. If the single disk fails you just need to restore the ibay.
If I understand the alternative, you are adding a single disk on top of a raid system, ie data can be written to the raid disks or the single disk, hence you won't know what data is on the raid or on the single disk, so if the extra disk fails you need to do a system restore.
Snoble 17:29, 18 September 2007 (MDT)
In the How-to there is a line in the intitial disclaimer that says:
Consider also that if this disk fails the whole system goes down.
I don't understand why that would be. If it was the SME LVM extended out to this disk (as in the discussion portion of the how-to) then I could see that being an issue. But if it is simply configured as an extra disk and then have symlink used to access it, I would expect that if you lost that drive you only lose access from the symlink but the rest of the system will run fine.
I would also like input on the /etc/mdadm.conf changes. I have simply added the line:
ARRAY /dev/md11
to the file as was done for the other existing arrays. But good practice seems to be to instead add the output of
mdadm --detail --scan --verbose
I kept it similar to the existing file only for consistancy and to reduce future conflict. What are your thoughts?
--Christian 16:22, 7 December 2008 (UTC)
Well I've tested the scenarios I can think of with the How-to and the worst I can see happening is that if it is in fstab with the options specified (ie. fsck). If there is a fatal disk errror then the system will stop at during boot at the fsck test. From there you can drop to the shell and remove the disk in fstab (or array) and then reboot and later fix your troubled system.
I'll update the how-to accordingly.
BTW, is there a better way to load the extra disk? Ideally I would like to load the disk automatically, do an fsck but not fail the system boot because of it. I'm not sure if there is an fstab option for this.
The only other way I could think of was to add something into rc.local or an earlier script. --Christian 02:19, 15 December 2008 (UTC)