On Wed, Jan 17, 2024, 9:35 PM gene heskett wrote:
> On 1/17/24 19:54, Steve McIntyre wrote:
> > Andy Smith wrote:
> ...
> >> Then there will just be people going by taste.
> >>
> >> Personally I still put them directly on drives. If I ever get taken
> >> out by one of those crappy motherboard
Hey Andy.
Andy Smith wrote:
>
>On Thu, Jan 18, 2024 at 12:53:43AM +, Steve McIntyre wrote:
>> I'm clearly a member of a third group of people,,, :-)
>
>Oh, I didn't mean to imply that those going by taste were in a
>minority! Taste, or possibly, "just never thought about it" could
>well be the
Hello,
On Thu, Jan 18, 2024 at 12:53:43AM +, Steve McIntyre wrote:
> I'm clearly a member of a third group of people,,, :-)
Oh, I didn't mean to imply that those going by taste were in a
minority! Taste, or possibly, "just never thought about it" could
well be the biggest group. I was only ta
needle in the haystack or do a fresh install. I prefer the
latter, because I can estimate the effort and I am reasonably confident
of the outcome.
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 app
ll. I prefer the
latter, because I can estimate the effort and I am reasonably confident
of the outcome.
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
Hi,
gene heskett wrote:
> > where did the extra 19.4G's come from? Can filesystem
> > ext4's overhead account for that?
In an earlier mail:
> > > command line: rsync -a --bwlimit=10m --fsync --progress /home/
> > > /mnt/homevol
David Christensen wrote:
> Please RTFM rsync(1) to choose your opt
On Tue, 16 Jan 2024 21:10:28 -0500
gene heskett wrote:
> gene@coyote:~/src/klipper-docs$ lsblk -d -o
> NAME,MAJ:MIN,MODEL,SERIAL,WWN /dev/sd[hijkl]
> NAME MAJ:MIN MODEL SERIAL WWN
> sdh8:112 Gigastone SSD GSTD02TB230102
> sdi8:128 Gigastone SSD GST02TBG221146
> sdj8:
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
inst
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 synapt
a 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 w
On Wed 17 Jan 2024 at 15:34:09 (-0500), gene heskett wrote:
> On 1/17/24 12:27, Thomas Schmitt wrote:
> > David Christensen wrote:
> > > I suspect the conflicting serial numbers are causing problems in the
> > > kernel,
> > > as indicated by the /dev/disk/by-id/* problems.
> >
> > That's not in t
On 1/17/24 19:54, Steve McIntyre wrote:
Andy Smith wrote:
The newer set of people recommending partitions are mostly doing so
because there's been a few incidents of "helpful" PC motherboards
detecting on boot what they think is a corrupt GPT, and replacing it
with a blank one, damaging the RAI
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 327268
Andy Smith wrote:
>
>The newer set of people recommending partitions are mostly doing so
>because there's been a few incidents of "helpful" PC motherboards
>detecting on boot what they think is a corrupt GPT, and replacing it
>with a blank one, damaging the RAID. This is a real thing that has
>happ
d/or standard error (via shell redirection).
A related issue is that lots of standard output can slow a program.
Minimizing a terminal can help. Redirecting standard output to a file
or to /dev/null can help, especially when done on the remote host while
using ssh(1).
The best solution is to
ection).
A related issue is that lots of standard output can slow a program.
Minimizing a terminal can help. Redirecting standard output to a file
or to /dev/null can help, especially when done on the remote host while
using ssh(1).
The best solution is to tell rsync(1) not to generate mess
On 1/17/24 16:16, Thomas Schmitt wrote:
Hi,
i wrote:
What did finally help ? Just the shorter terminal scroll back memory ?
gene heskett wrote:
That, and possibly the --bwlimit=10m, giving the SSD time to keep their
stuff in one sock.
Then i place my bet on the terminal alone.
Linux is
Hi,
i wrote:
> > What did finally help ? Just the shorter terminal scroll back memory ?
gene heskett wrote:
> That, and possibly the --bwlimit=10m, giving the SSD time to keep their
> stuff in one sock.
Then i place my bet on the terminal alone.
Linux is able to handle disk-to-disk
On 1/17/24 09:31, Thomas Schmitt wrote:
Hi,
David Christensen wrote:
I suspect the conflicting serial numbers are causing problems in the kernel,
as indicated by the /dev/disk/by-id/* problems.
That's not in the kernel but in udev/systemd's process of creating the
symbolic links in /dev/disk/
that machine
at the same time.
Should not be a problem if labeled uniquely. And that's easily affected
by gparted.
One of you made the remark that seems to be the secret password.
What did finally help ? Just the shorter terminal scroll back memory ?
That, and possibly the --bwlim
On 1/17/24 12:27, Thomas Schmitt wrote:
Hi,
David Christensen wrote:
I suspect the conflicting serial numbers are causing problems in the kernel,
as indicated by the /dev/disk/by-id/* problems.
That's not in the kernel but in udev/systemd's process of creating the
symbolic links in /dev/disk/
On 1/17/24 12:16, Thomas Schmitt wrote:
Hi,
Curt wrote:
I discovered a couple of discussions of the phenomenon, the upshot of which
were:
1) That's what you get when you purchase cheap SSDs.
https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/
2) SSDs be
On 1/17/24 11:38, Curt wrote:
On 2024-01-17, Thomas Schmitt wrote:
This is just weird.
I still have difficulties to believe that any disk manufacturer would
hand out disks with colliding serial numbers. I googled for this
phenomenon, but except two mails of Gene nothing similar popped up.
I
hould not be a problem if labeled uniquely. And that's easily affected
by gparted.
One of you made the remark that seems to be the secret password.
What did finally help ? Just the shorter terminal scroll back memory ?
That, and possibly the --bwlimit=10m, giving the SSD time to keep their
Hi,
i see that i messed up "h" and "k" in my explanation of the fight over
the link targets in /dev/disk/by-id. So another attempt:
sdh has a unique serial number GSTD02TB230102. Thus we see in
https://lists.debian.org/debian-user/2024/01/msg00667.html
these two links:
/dev/sdh/dev/d
Hi,
David Christensen wrote:
> I suspect the conflicting serial numbers are causing problems in the kernel,
> as indicated by the /dev/disk/by-id/* problems.
That's not in the kernel but in udev/systemd's process of creating the
symbolic links in /dev/disk/by-id/.
It gets /dev/sd[h-l] and /dev/sd
Hi,
Curt wrote:
> I discovered a couple of discussions of the phenomenon, the upshot of which
> were:
> 1) That's what you get when you purchase cheap SSDs.
> https://www.reddit.com/r/truenas/comments/s0rrpo/two_sata_ssds_with_identical_serial_numbers/
> 2) SSDs belonging to the same software RAID
On 1/17/24 06:18, gene heskett wrote:
On 1/17/24 00:52, David Christensen wrote:
I suggest removing one GST02TBG221146 and one GSTG02TB230206. Put
them on the shelf, in other computer(s), or sell them. Then perhaps
copying the /home RAID10 2 TB to one Gigastone 2 TB SSD would work.
Or LABEL
On 1/16/24 23:46, Thomas Schmitt wrote:
Gene Heskett wrote:
One of these mails from a thread in december reveals that the three
unique serial numbers GSTD02TB230102, GST02TBG221146, GSTG02TB230206
each come with a different version of "1C0", "7A0", "5A0", respectively.
https://www.mail-archive
On 2024-01-17, Thomas Schmitt wrote:
>
> This is just weird.
> I still have difficulties to believe that any disk manufacturer would
> hand out disks with colliding serial numbers. I googled for this
> phenomenon, but except two mails of Gene nothing similar popped up.
I discovered a couple of di
so, one would have to make sure that
it is not some weird effect of them all being plugged into that machine
at the same time.
> One of you made the remark that seems to be the secret password.
What did finally help ? Just the shorter terminal scroll back memory ?
It would explain why a ver
On 1/17/24 02:42, Thomas Schmitt wrote:
Hi,
Gene Heskett wrote:
lsblk, which I've published several times, shows 5 drives.
Duh. Obviously this thread overstretches my mental capacity.
And I've since tried cp in addition to rsync, does the same thing, killing
the sysytem with the OOM but mu
On 1/17/24 00:52, David Christensen wrote:
On 1/16/24 17:08, gene heskett wrote:
> lsblk, which I've published several times, shows 5 drives. by-id listing
> only shows 3. The drive I've been trying to use bounces from /dev/sdd to
> sde to sdh dependin on which controller it is curently plugge
Hi,
Gene Heskett wrote:
> lsblk, which I've published several times, shows 5 drives.
Duh. Obviously this thread overstretches my mental capacity.
> And I've since tried cp in addition to rsync, does the same thing, killing
> the sysytem with the OOM but much quicker. cp using all system memory
On 1/16/24 17:08, gene heskett wrote:
> lsblk, which I've published several times, shows 5 drives. by-id listing
> only shows 3. The drive I've been trying to use bounces from /dev/sdd to
> sde to sdh dependin on which controller it is curently plugged into.
>
> And I've since tried cp in addition
gene heskett composed on 2024-01-16 20:08 (UTC-0500):
> Felix Miata wrote:
>> I straightened out the wrapping mess, and gave each entry a line number. I
>> see
>> nothing I recognize as representing serial number duplication among /dev/sdX
>> (physical device) names:
>> /dev/sda 9 /dev/dis
On 1/16/24 11:08, Thomas Schmitt wrote:
ls -l /dev/sd[ij]*
oot@coyote:~# ls -l /dev/sd[ij]*
brw-rw 1 root disk 8, 128 Jan 16 05:01 /dev/sdi
brw-rw 1 root disk 8, 129 Jan 16 05:01 /dev/sdi1
brw-rw 1 root disk 8, 144 Jan 16 05:01 /dev/sdj
brw-rw 1 root disk 8, 145 Jan 16 05:01 /
On 1/16/24 06:09, Felix Miata wrote:
Tom Furie composed on 2024-01-16 08:18 (UTC):
Felix Miata writes:
/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
So this pol
On Tue 16 Jan 2024 at 20:08:12 (-0500), gene heskett wrote:
> On 1/16/24 00:56, Felix Miata wrote:
> > gene heskett composed on 2024-01-15 17:56 (UTC-0500):
> >
> > > Thanks for that composition: but it will be word wrapped:
> > > root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
>
On 1/16/24 01:18, Felix Miata wrote:
Felix Miata composed on 2024-01-16 01:05 (UTC-0500):
gene heskett composed on 2024-01-15 18:37 (UTC-0500):
Ah,but I finally glombed onto the bug tan memory bar in htop as it was
runniing, someplace in the data chain is a huge memory leak, my crash is
caus
On 1/16/24 01:05, Felix Miata wrote:
gene heskett composed on 2024-01-15 18:37 (UTC-0500):
Ah,but I finally glombed onto the bug tan memory bar in htop as it was
runniing, someplace in the data chain is a huge memory leak, my crash is
caused by the OOM daemon killing things. And it only occurs
On 1/16/24 00:56, Felix Miata wrote:
gene heskett composed on 2024-01-15 17:56 (UTC-0500):
Thanks for that composition: but it will be word wrapped:
root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
"$(realpath "$j")" "$j" ; done
/dev/sr0/dev/disk/by-id/ata-ATAPI_iHAS424_
On Tue 16 Jan 2024 at 06:08:35 (-0500), Felix Miata wrote:
> Tom Furie composed on 2024-01-16 08:18 (UTC):
> > Felix Miata writes:
>
> >> /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
> >> How does a printer get a storage device assignment???
>
> > By having some kind of
On Tue 16 Jan 2024 at 09:40:19 (-0500), Greg Wooledge wrote:
> On Tue, Jan 16, 2024 at 09:31:54AM -0500, Felix Miata wrote:
> > David Wright composed on 2024-01-16 08:05 (UTC-0600):
> > > On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
> > >> gene heskett composed on 2024-01-15 17:56 (UT
Hello,
On Tue, Jan 16, 2024 at 01:01:02PM -0800, David Christensen wrote:
> On 1/16/24 11:51, Franco Martelli wrote:
> > I thought it was mandatory for a RAID to partition drives with this
> > partition type, am I wrong?
In the ancient past it was required, because that was one of the
ways that m
On 1/16/24 11:51, Franco Martelli wrote:
On 15/01/24 at 08:43, David Christensen wrote:
When I built and ran a Debian 2 @ HDD RAID1 using mdadm(8), I did not
partiton the HDD's -- I gave mdadm(8) the whole drives.
I don't know if it is a good idea, in fact it exists a special partition
type f
On 15/01/24 at 08:43, David Christensen wrote:
This I am still trying to do, the first pass copied all 350G of /home
but went to the wrong drive, and I had mounted the drive by its label.
It is now /dev/sdh and all labels above it are now wrong. Crazy.
These SSD's all have an OTP serial number.
Hello,
On Tue, Jan 16, 2024 at 01:17:42AM -0500, Felix Miata wrote:
> If rsync really is bugged, maybe a change of options would avoid the bug. Try
> instead of -av, -rlptgoDAXUNH. Could it be that verbosity is the OOM
> crippler, and
> not necessarily from rsync itself, but possibly from the xte
Hi,
i, too, wondered where there should be a duplicate serial number.
But indeed:
David Wright wrote:
> > /dev/sdi53 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146
> > /dev/sdj1 54 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1
> ↑ that is /really/ bad!
Does the numbe
On 16/01/2024 15:18, Tom Furie wrote:
/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
I have heard that some devices expose a USB mass storage interface out
of the box
On Tue, Jan 16, 2024 at 09:31:54AM -0500, Felix Miata wrote:
> David Wright composed on 2024-01-16 08:05 (UTC-0600):
>
> > On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
>
> >> gene heskett composed on 2024-01-15 17:56 (UTC-0500):
>
> >>> Thanks for that composition: but it will be w
David Wright composed on 2024-01-16 08:05 (UTC-0600):
> On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
>> gene heskett composed on 2024-01-15 17:56 (UTC-0500):
>>> Thanks for that composition: but it will be word wrapped:
>>> root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\
On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote:
> gene heskett composed on 2024-01-15 17:56 (UTC-0500):
>
> > Thanks for that composition: but it will be word wrapped:
> > root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
> > "$(realpath "$j")" "$j" ; done
> > /dev/sr0
Il 16/01/2024 12:08, Felix Miata ha scritto:
Tom Furie composed on 2024-01-16 08:18 (UTC):
Felix Miata writes:
/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
So
Tom Furie composed on 2024-01-16 08:18 (UTC):
> Felix Miata writes:
>> /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
>> How does a printer get a storage device assignment???
> By having some kind of SD card slot or similar.
So this pollution only results from a USB-conn
Felix Miata writes:
> /dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
> How does a printer get a storage device assignment???
By having some kind of SD card slot or similar.
Felix Miata composed on 2024-01-16 01:05 (UTC-0500):
> gene heskett composed on 2024-01-15 18:37 (UTC-0500):
>> Ah,but I finally glombed onto the bug tan memory bar in htop as it was
>> runniing, someplace in the data chain is a huge memory leak, my crash is
>> caused by the OOM daemon killing
gene heskett composed on 2024-01-15 18:37 (UTC-0500):
> Ah,but I finally glombed onto the bug tan memory bar in htop as it was
> runniing, someplace in the data chain is a huge memory leak, my crash is
> caused by the OOM daemon killing things. And it only occurs when I run
> rsync. Only takes
gene heskett composed on 2024-01-15 17:56 (UTC-0500):
> Thanks for that composition: but it will be word wrapped:
> root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
> "$(realpath "$j")" "$j" ; done
> /dev/sr0/dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865
> /dev/s
On Mon 15 Jan 2024 at 18:27:14 (-0500), gene heskett wrote:
> On 1/15/24 14:57, David Wright wrote:
> > On Sun 14 Jan 2024 at 20:15:16 (-0500), gene heskett wrote:
> > > On 1/14/24 18:57, Felix Miata wrote:
> > > > gene heskett composed on 2024-01-14 18:39 (UTC-0500):
> > > > > Felix Miata wrote:
>
On Mon 15 Jan 2024 at 20:31:55 (-0500), gene heskett wrote:
> On 1/15/24 19:11, David Christensen wrote:
> > On 1/15/24 16:03, gene heskett wrote:
> > > On 1/15/24 18:41, gene heskett wrote:
> > > > On 1/15/24 17:58, gene heskett wrote:
> > > > > On 1/15/24 14:55, David Wright wrote:
> > > > > > On
On 1/15/24 17:31, gene heskett wrote:
On 1/15/24 19:11, David Christensen wrote:
On 1/15/24 16:03, gene heskett wrote:
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
On 1/15/24 19:11, David Christensen wrote:
On 1/15/24 16:03, gene heskett wrote:
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
ata-Gigastone_SSD_GST02TBG221146
ata-
On 1/15/24 16:03, gene heskett wrote:
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
ata-Gigastone_SSD_GST02TBG221146
ata-Gigastone_SSD_GSTD02TB230102
ata-Gigastone_S
On 1/15/24 15:53, gene heskett wrote:
On 1/15/24 18:15, David Christensen wrote:
On 1/15/24 14:56, gene heskett wrote:
root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
"$(realpath "$j")" "$j" ; done
/dev/sr0 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865
/dev/s
On 1/15/24 18:41, gene heskett wrote:
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
On 1/14/24 20:19, gene heskett wrote:
On 1/14/24 19:48, David Wright wrote:
On Sun 14 Jan 2024 at 14:48:49 (-0500), ge
On 1/15/24 18:15, David Christensen wrote:
On 1/15/24 14:56, gene heskett wrote:
root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
"$(realpath "$j")" "$j" ; done
/dev/sr0 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865
/dev/sdi /dev/disk/by-id/ata-Gigastone
On 1/15/24 15:37, gene heskett wrote:
On 1/15/24 16:51, David Christensen wrote:
I think your computer has numerous issues, including storage. Unless
and until you benchmark the Gigastone SSD's in a stripped-down machine
with a reference OS and tool set, I would not blame the Gigastone SSD's.
On 1/15/24 17:58, gene heskett wrote:
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
On 1/14/24 20:19, gene heskett wrote:
On 1/14/24 19:48, David Wright wrote:
On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
On 1/14/24 07:42, Da
On 1/15/24 16:51, David Christensen wrote:
On 1/15/24 06:45, gene heskett wrote:
On 1/15/24 02:45, David Christensen wrote:
On 1/14/24 11:48, gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
... the 2dn seagate 2T drive failure was my amanda vtapes drive, and
bookworm has been s
On 1/15/24 14:57, David Wright wrote:
On Sun 14 Jan 2024 at 20:15:16 (-0500), gene heskett wrote:
On 1/14/24 18:57, Felix Miata wrote:
gene heskett composed on 2024-01-14 18:39 (UTC-0500):
Felix Miata wrote:
My point was entirely about suitability of /mnt/ for fstab entries.
And my point is
On 1/15/24 14:56, gene heskett wrote:
root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n'
"$(realpath "$j")" "$j" ; done
/dev/sr0 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865
/dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146
/dev/sdj1 /dev/dis
ul tools. I suggest you build whichever corresponds to
your computer, and use it to help with trouble shooting, backups, etc..
David
On 1/15/24 14:55, David Wright wrote:
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
On 1/14/24 20:19, gene heskett wrote:
On 1/14/24 19:48, David Wright wrote:
On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
I am confused
On 1/15/24 13:44, Felix Miata wrote:
gene heskett composed on 2024-01-15 08:39 (UTC-0500):
└─md2 9:20 3G 0 raid10
sdh 8:112 0 1.9T 0 disk
└─sdh18:113 0 1.9T 0 part <<< the one I'm fooling with
sdi 8:128 0 1.9T 0 disk
└─sdi18:12
On 1/15/24 06:45, gene heskett wrote:
On 1/15/24 02:45, David Christensen wrote:
On 1/14/24 11:48, gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
... the 2dn seagate 2T drive failure was my amanda vtapes
drive, and bookworm has been such a headache I not managed to restart it
On Sun 14 Jan 2024 at 20:15:16 (-0500), gene heskett wrote:
> On 1/14/24 18:57, Felix Miata wrote:
> > gene heskett composed on 2024-01-14 18:39 (UTC-0500):
> > > Felix Miata wrote:
> > > > My point was entirely about suitability of /mnt/ for fstab entries.
> > > And my point is that for a one time
On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:
> On 1/14/24 20:19, gene heskett wrote:
> > On 1/14/24 19:48, David Wright wrote:
> > > On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
> > > > On 1/14/24 07:42, David Christensen wrote:
> > >
> > > > > I am confused -- do you
gene heskett composed on 2024-01-15 08:39 (UTC-0500):
>└─md2 9:20 3G 0 raid10
> sdh 8:112 0 1.9T 0 disk
> └─sdh18:113 0 1.9T 0 part <<<
> sdi 8:128 0 1.9T 0 disk
> └─sdi18:129 0 1.9T 0 part <<<
> sdj 8:144 0 1.9T
On 1/15/24 02:45, David Christensen wrote:
and rsync just locked me up for about the 8th time, requiring the reset
button. And that was at a --bwlimit=5m.
rebooted, running test=short on the SSD, looks fine
restarted rsync -av --bwlimit=3m, but its hung on an .local~akonadi
.glass file, two of
On 1/15/24 02:45, David Christensen wrote:
On 1/14/24 11:48, gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
Re-ordered for clarity -- David.
And snipped by Gene as I updated
[...]
which aren't atm, the 2dn seagate 2T drive failure was my amanda vtapes
drive, and bookworm has
On 1/14/24 20:19, gene heskett wrote:
On 1/14/24 19:48, David Wright wrote:
On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
I am confused -- do you have 4 or 5 Gigastone 2 TB SSD?
5, ordered in 2 separate orders.
> So that one cou
On 1/14/24 11:48, gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
Re-ordered for clarity -- David.
And snipped by Gene as I updated
On 1/12/24 18:42, gene heskett wrote:
I just found an mbox file in my home directory, containing about 90
days worth of undelivered msgs from sma
On Sun, Jan 14, 2024 at 06:15:13PM -0500, gene heskett wrote:
[...]
> /home/coyotebak would be in the raid, but something in the system
> /backupdisk/ as a mount point would not be in the raid. But I have mount
> points scattered about this system, literaaly all over that just work, since
> when
On Sun, Jan 14, 2024 at 01:37:05PM -0500, Felix Miata wrote:
> tomas composed on 2024-01-14 19:15 (UTC+0100):
[Gene]
> >> > I have not been able to use that last line as a target for rsync
>
> >> That's not unexpected. /mnt/ is intended for /temporary/ or /transient/
> >> mounting,
> >> while
gene heskett composed on 2024-01-14 20:03 (UTC-0500):
> Felix Miata wrote:
>> I'm only suggesting you find a place other than /mnt/ for anything found in
>> /etc/fstab, based upon the definition of /mnt/ in FHS. Conforming your
>> machinery
>> to FHS is not mandatory, just recommended, a good id
directories of every machine on the premises. I have a script
in my private bin directory that mounts them all. I get tired of
repeating my user pw while the script is running, but it just works.
When I save a file, I use bash-completion to help write directory
names etc, but I know where I'm
On 1/14/24 19:48, David Wright wrote:
On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
On 1/14/24 07:42, David Christensen wrote:
I am confused -- do you have 4 or 5 Gigastone 2 TB SSD?
5, ordered in 2 separate orders.
> So that one could be formatted ext4 and serve as a bac
On 1/14/24 18:57, Felix Miata wrote:
gene heskett composed on 2024-01-14 18:39 (UTC-0500):
Felix Miata wrote:
AFAIK, nothing I wrote would be expected to have any relationship to transfer
rates. My point was entirely about suitability of /mnt/ for fstab entries.
And my point is that for a o
ctories of every machine on the premises. I have a script
> in my private bin directory that mounts them all. I get tired of
> repeating my user pw while the script is running, but it just works.
When I save a file, I use bash-completion to help write directory
names etc, but I know where
On 1/14/24 18:43, Felix Miata wrote:
gene heskett composed on 2024-01-14 18:15 (UTC-0500):
Felix Miata wrote:
...
I have mount
points scattered about this system, literaaly all over that just work,
Fine! It's your stuff.
since when is /mnt some special thing?
Since 1994, 30 years ago ne
On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:
> On 1/14/24 07:42, David Christensen wrote:
> > I am confused -- do you have 4 or 5 Gigastone 2 TB SSD?
>
> 5, ordered in 2 separate orders.
> >
> > > So that one could be formatted ext4 and serve as a backup of the raid10.
> What I
gene heskett composed on 2024-01-14 18:39 (UTC-0500):
> Felix Miata wrote:
>> AFAIK, nothing I wrote would be expected to have any relationship to transfer
>> rates. My point was entirely about suitability of /mnt/ for fstab entries.
> And my point is that for a one time copy, its was handy. I d
gene heskett composed on 2024-01-14 18:15 (UTC-0500):
> Felix Miata wrote:
...
> I have mount
> points scattered about this system, literaaly all over that just work,
Fine! It's your stuff.
> since when is /mnt some special thing?
Since 1994, 30 years ago next month:
...
http://www.ibiblio.
On 1/14/24 13:37, Felix Miata wrote:
tomas composed on 2024-01-14 19:15 (UTC+0100):
On Sun, Jan 14, 2024 at 12:33:39PM -0500, Felix Miata wrote:
gene heskett composed on 2024-01-14 12:04 (UTC-0500):
# first put it where it is now & reboot
#LABEL=homesde1 /mnt/homesde1 ext4 errors=remount-
On 1/14/24 12:34, Felix Miata wrote:
gene heskett composed on 2024-01-14 12:04 (UTC-0500):
# first put it where it is now & reboot
#LABEL=homesde1 /mnt/homesde1 ext4 errors=remount-ro 0 2
...
I have not been able to use that last line as a target for rsync
That's not unexpected. /mnt/ is in
On 1/14/24 09:15, Greg Wooledge wrote:
On Sun, Jan 14, 2024 at 11:58:42AM +, Andrew M.A. Cater wrote:
You now have a slow access to one/more of your RAID devices.
Does he, though? I thought we had established some time late last
year that his *symptom* (delayed startup of some application
On 1/14/24 07:42, David Christensen wrote:
Re-ordered for clarity -- David.
And snipped by Gene as I updated
On 1/12/24 18:42, gene heskett wrote:
I just found an mbox file in my home directory, containing about 90
days worth of undelivered msgs from smartctl running as root.
Do you know h
tomas composed on 2024-01-14 19:15 (UTC+0100):
> On Sun, Jan 14, 2024 at 12:33:39PM -0500, Felix Miata wrote:
>> gene heskett composed on 2024-01-14 12:04 (UTC-0500):
>> > # first put it where it is now & reboot
>> > #LABEL=homesde1 /mnt/homesde1 ext4 errors=remount-ro 0 2
>> ...
>> > I have not
On Sun, Jan 14, 2024 at 12:33:39PM -0500, Felix Miata wrote:
> gene heskett composed on 2024-01-14 12:04 (UTC-0500):
>
> > # first put it where it is now & reboot
> > #LABEL=homesde1 /mnt/homesde1 ext4 errors=remount-ro 0 2
> ...
> > I have not been able to use that last line as a target for rsync
201 - 300 of 19700 matches
Mail list logo
