On 1/18/24 00:50, David Christensen wrote:
On 1/17/24 20:20, gene heskett wrote:
On 1/17/24 19:58, David Christensen wrote:
On 1/17/24 15:58, gene heskett wrote:
Now the question is how did it make this: homevol s/b very close to
/home in size but:
root@coyote:~# df && free
Filesystem 1K-blocks Used Available Use% Mounted on
udev 16327704 0 16327704 0% /dev
tmpfs 3272684 1912 3270772 1% /run
/dev/sda1 863983352 22348472 797673232 3% /
tmpfs 16363420 1244 16362176 1% /dev/shm
tmpfs 5120 8 5112 1% /run/lock
/dev/sda3 47749868 784 45291076 1% /tmp
/dev/md0p1 1796382580 335102676 1369954928 20% /home
tmpfs 3272684 4956 3267728 1% /run/user/1000
/dev/sdh1 1967892164 354519236 1513336680 19% /mnt/homevol
total used free shared
buff/cache available
Mem: 32726840 3417576 515520 934540 30072184
29309264
Swap: 111902712 2048 111900664
root@coyote:~#
It somehow changed 335G into 354G. Thinking the AppImages dir is
full of soft links of short names pointing at the long filename and
had turned the links into duplicates, that was the first thing I
checked, but it was all good soft-links, so where did the extra
19.4G's come from? Can filesystem ext4's overhead account for that?
I suggest running rsync(1) with --dry-run, --log-file=FILE,
--itemize_changes, and whatever other options are needed to find the
differences. Please RTFM rsync(1) to choose your options. These
look useful:
--archive, -a (-rlptgoD)
--delete
Why --delete?
If you have files on the destination from a previous run of rsync(1) and
they no longer exist on the source, --delete will get rid of extraneous
files on the destination.
--hard-links, -H
--one-file-system, -x
--sparse, -S
or --sparse?
First, you need to understand what "sparse file" means:
https://en.wikipedia.org/wiki/Sparse_file
If you have sparse files on the source -- say, 10 GB virtual machine
images -- then you want rsync(1) to create sparse files on the destination.
Well, my abundance of curiosity, may have killed the cat, but if I
understand how rsync's -a works, re-running the same command will only
update for the incoming email and any posts I've made while it was
running the first time. So the same command quoted last is now
running again. when it has exited, which it has now done in about 15
minutes I'll edit fstab to remove the 60 gigs of swap on md1, remove
the existing mount of md0p1 as /home taking the raid10 completely out
of the system. And add the mounting of LABEL=homevolsdh1 as the /home
partition and reboot. In the event I have to re-install, the raid will
still contain my data and can be recovered.
I already have a dvd with the most recent netinstall burnt. All I have
to do is convince it to not install orca and brltty. Probably by
unplugging _all_ usb stuff except the keyboard and mouse buttons.
What would solve many of my problems is a bit of help from someone who
it running trinity to tell me how to install it on a system w/o any
installed gui which obviously disables synaptic. That leaves apt,
apt-get, and aptitude, unless there is a better way. aptitude is
uncontrollable, has fixed me once, has torn the system down to another
install 3 times so the odds are not in my favor.
So those fstab edits have been done, next is a reboot
You should be able to migrate your /home file system from RAID10 to an
SSD without needing to reinstall Debian.
The migration took two passes because udev can't make up its alleged
mind so I was finally forced to use the rescue mode to edit fstab to
mount it by UUID and that worked, I've got /home on the copy right now.
and I took the 60 G's of swap out too since I've never used more the 20G
with any gfx program, so I figure 47G's on /dev/sda is enough. So now
none of the raid is mounted, but the 30+ second lag when opening a write
path is still there, so I was erroneously blaming the raid. So I've
narrowed the problem but w/o a good clue what to do next. One thing that
bothers me is there is no way the installers parted shows partition
names for non-raid disks. To me that is a serious bug. It appears from
the help that it can LABEL a partition but can't read that LABEL. parted
when asked to print all does that just fine, but the | doesn't put it to
less, so it scrolls off screen the top 60% of a parted's print all
output at some fraction of C speed. Not exactly helpful. I have other
things to do while I cogitate on what to do next. Many thanks to all
that helped.
If you use rsync(1), I suggest using some kind of integrity checking
tool to verify that the source and destination file systems are
identical. I prefer BSD mtree(8):
I assume I'd have to remount the raid like to /raid?
Whew! That's got more arguments than rsync...
https://manpages.debian.org/bullseye/mtree-netbsd/mtree.8.en.html
(Be careful not to confuse the above with mtree(5) via libarchive.)
David
.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
