I have two 4T drives in this machine. I mount them as /u1 and /u2 and /u2 is a mirror of /u1. I have been getting messages from the u1 drive like so:
Dec 8 04:14:46 trona smartd[1009]: Device: /dev/sdc [SAT], 2 Currently unreadable (pending) sectors Dec 8 04:14:46 trona smartd[1009]: Device: /dev/sdc [SAT], 2 Offline uncorrectable sectors Dec 8 04:44:46 trona smartd[1009]: Device: /dev/sdc [SAT], 2 Currently unreadable (pending) sectors Dec 8 04:44:46 trona smartd[1009]: Device: /dev/sdc [SAT], 2 Offline uncorrectable sectorsThe disk has not actually failed, but the word in general is that when you start seeing things like this, doom is right around the corner.
So, I purchased a replacement drive. It is a WD4000FYYZ. Date is marked 20 May 2014 on the drive, so this is either old stock or a refurbished drive. I edit fstab so that it mounts "sdd" as /u1, swap the "sdc" drive and boot back up. My system is installed on a pair of SSD which are sda and sdb so this works.
Disk /dev/sdd: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD4000FYYZ-0 Device Start End Sectors Size Type /dev/sdd1 2048 98303 96256 47M Linux filesystem /dev/sdd2 98304 31445312 31347009 14.9G Linux swap /dev/sdd3 31445313 7814037134 7782591822 3.6T Linux filesystemGood old fdisk is limited to 2T drives, so I need to use something else to partition the new disk, namely "parted"
parted /dev/sdcThe trick is using the "mkpart" command. Everything is referenced to the start of the disk, which is pretty inconvenient. I have notes about a previous trial and error to sort this all out. I give a start somewhere inside the prior partition, and then parted scolds me and offers to set the start to immediately follow that partition, which is what I want. I ended up with pretty much the following. You can type "mklabel" at any time to start over.
A hot tip. I am writing this page as I do all of this, so I use vim to type the following, then cut and paste it into the window with parted which avoids stupid typos. I do this a lot for boring sysadmin tasks like this.
print mklabel GPT mkpart "extra" ext4 1 48m mkpart "swap" linux-swap 40m 16.1g mkpart "u3" ext4 8g -1s print quit
Yes, you just quit and it is for real, unlike fdisk.
After this was done I did:
mkfs -t ext4 /dev/sdc1 mkfs -t ext4 /dev/sdc3
df /u1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdd3 3829075716 2651532844 982961696 73% /u1We will leave the new disk on /u2 for now and edit fstab to put it back to /u1 when the copy is all done.
su mount /dev/sdc3 /u2 cd /u1 umask 0 tar cf - . | ( cd /u2 ; tar xpf - )For some insane reason, it is extracting all the files as owned by root and with restricted permissions:
drwx------ 10 root root 4096 Dec 13 09:57 android-ndk-r8d drwx------ 7 root root 4096 Dec 13 09:57 idea-IC-231.9161.38 drwx------ 2 root root 16384 Dec 13 09:56 lost+found drwx------ 32 root root 4096 Dec 13 09:58 tom_archiveI use "tar cf /u2/junk.tar ." to see what it is putting in the tar file and all the ownerships and permissions in the file are correct. There are flags "-o" and "-m". I don't recall ever having to use them before.
umount /u2 mkfs -t ext4 /dev/sdc3 mount /dev/sdc3 /u2 cd /u1 tar cf - . | ( cd /u2 ; tar xpf - ) #tar cf - . | ( cd /u2 ; tar xpf - -o -m )But it doesn't work. Everything still gets created owned by root and as if there is a umask of 077 (turning off all access for other users). This smells like some ill conceived security "feature" that the Fedora group has sneaked in.
cd /u1/home tar cpf /u2/tom.tar ./tom cd /u2/home tar xpvf ../tom.tarAnd this works! All the files in /u2/home/tom have proper ownerships and permissions. Why would tar extraction from a file work, but not from a pipeline?
I try a reboot with /u2 in the fstab -- no better.
I try this:
root@trona:/u1# tar cf - . | tar tvf - | more drwxr-xr-x tom/tom 0 2024-08-28 17:34 ./ drwxr-xr-x tom/tom 0 1970-01-20 05:40 ./idea-IC-231.9161.38/ drwxr-xr-x tom/tom 0 1970-01-20 05:40 ./idea-IC-231.9161.38/lib/This confirms that the tar create is working as it should, placing both ownerships and permissions into the "file".
grubby --update-kernel ALL --args selinux=0And of course we will need to reboot again. This does not do it.
What about flipping the tar subshell thing around:
cd /u2 ( cd /u1 ; tar cf - . ) | tar xpvf -Nope -- this also fails.
Now try this:
cd /home/tom ( cd /u1 ; tar cf - . ) | ( cd /u2 ; tar xpf - )Nope -- no magic in this.
rsync -auv --exclude-from=/u1/Backup/trona_excludes --delete /u1/ /u2No! This has the same trouble.
I considered letting this run and writing a script to fix ownership and permissions for the top level directories, but then discovered that there were also issues deeper into the filesystem.
I ended up doing this:
mount /u2 chown tom:tom /u2 cd /u1 cp -arp . /u2It took over 10 hours, but the result seems fine.
The theory is that tar, when finished, would have made it all right. I was looking at things while tar was still busy, for example looking at a huge tar file, as well as directories that files were still being written into. I would have had to let it run for 10 hours and then taken a look.
This would also explain why my small scale experiments all worked. I looked at permissions once tar has finished.
At this point I don't really care and have moved on to other things.
Adventures in Computing / tom@mmto.org