On Sat, Feb 23, 2019 at 06:32:43PM +1100, Andrew Greig wrote:
1. unmount both of them
$sudo umount /dev/sdb1 && umount /dev/sdc1 ?
or "sudo umount /data0 /data1" as long as no process has any file open under those directories (and that includes having a shell with it's current working directory in either of them - you can't unmount a filesystem that is being actively used), both directories will be unmounted.
2. remount ONE of them (say, data0) as /data (and edit /etc/fstab so that it gets mounted as /data on every reboot. also delete the line in fstab that mounts data1).
Here is my current fstab (please note, partition manager took me an hour and a half to negotiate and I was unable to install swap on my SSD so I put a swap partition on each of the two SATA drives so that they would be exactly the same size. )
That's a shame because swap on SSD is much faster than swap on HDD. Of course when you upgrade your RAM, it probably won't swap much. Once you get your RAM upgrade installed, I strongly recommend that you install libvirt and virt-manager and create some VMs to play with. e.g. make a VM and give it three 5GB disk image files (i.e. similar to your current system with three drives). Then install ubuntu onto it. you can mess around with the partition manager (or even fdisk on the command line) until you understand how it works without risking anything on your real system. and try different variations on the build (e.g. install ubuntu onto one of the VM's virtual disks, boot it up, and then manually partition the other two virtual disks and aformat them with btrfs and add them to fstab. and experiment also with other filesystems and/or mdadm and/or lvm2 if you like). That's one of the things VMs are good for, to experiment and test things and especially to learn. In fact, they're an excellent way to learn stuff. Things like partition management and formatting partitions are hard and a bit scary because they are things that are very rarely done by most people - only when building a new machine or adding new drives to a machine. Practice is the only thing that will make it familiar and comfortable. Do this every few months to keep the memory fresh so that you will know what to do and how to do it if/when you ever need to.
# /data0 was on /dev/sdb2 during installation UUID=0e8718c8-03bf-4f1a-915f-df03fe117dc0 /data0 btrfs defaults 0 2
edit this line, change data0 to data.
# /data1 was on /dev/sdc2 during installation UUID=5969127b-f5e0-40dc-98ba-ea7252c9ee41 /data1 btrfs defaults 0 2
delete or comment out this line. then, save & exit, and run "sudo mount /data"
# /efi was on /dev/sda1 during installation UUID=b588608e-8cf7-43be-8a53-03dfde6f8f15 /efi btrfs defaults 0 2
the EFI partition should be FAT32. UEFI can't use btrfs. I guess that means it's not being used at all - your machine is either old-fashioned BIOS or, if UEFI, it's configured for legacy (BIOS) boot.
3. destroy the partition table on the data1 drive, and recreate it (again, one big partition for the entire disk[1])
So by deleting the partition we eliminate the FS (btrfs) and in the addition step the FS is rebuilt?? but specifically to control both disks?
No, it's just deleting and re-creating the partition. creating a partition and formatting it are two different things. A partition is just a chunk of disk space reserved for some particular use. That use can be to be formatted as one of several different filesystems (ext4, xfs, btrfs, fat32, etc etc), to be used as swap space, for an lvm physical volume (PV), or just left unused. But now that i know you've got a swap partition on there, DON'T DELETE THE ENTIRE PARTITION TABLE. Just delete /dev/sdc2. better yet, don't bother deleting it at all, this step can be skipped. You can actually skip step 3 entirely: the '-f' option used in step 4 ('btrfs device add -f ...') should force it to use /dev/sdc2 even though it is already formatted as btrfs.
Can /dev/sdc2 can be deleted with gparted?
yes.
4. add that drive to the existing btrfs array on /data
e.g. *IF* /data1 was sdc1, you'd do something like:
sudo btrfs device add -f /dev/sdc1 /data sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /data
change sdc1 here to sdc2.
The earlier you do this (i.e. the less data is already on it), the faster this conversion to raid1 will be. Nearly instant if there's little or no data. Much longer if there's a lot of data that needs to be synced to the other drive.
i.e. best to do it before copying the data from your old drive.
I have about 4Gb only of data from this morning's photo shoot, I can move that back to /home/andrew easily enough. I just tried the Data drive to see how my CHOWN went. ( I cheat, I use mc)
No need. 4GB of data will be synced in very little time. craig -- craig sanders <cas@taz.net.au>