Ramon Fischer wrote:
> Hi Dale,
>
>> So, something says it is busy but eventually
>> releases it if left alone for a while. I'd like to know what it is and
>> if it is really in use or not. Thing is, I can't find a way to know
>> what it is that is using it. The dmsetup command shows it is in
Hi Dale,
So, something says it is busy but eventually
releases it if left alone for a while. I'd like to know what it is and
if it is really in use or not. Thing is, I can't find a way to know
what it is that is using it. The dmsetup command shows it is in use but
no way to know what is usi
Ramon Fischer wrote:
> OK, if it could be "udev", you might want to try to check the following:
>
> $ grep -rF "" /etc/udev/rules.d/
> $ grep -rF "" /lib/udev/rules.d/
> $ grep -rF "" /etc
>
> You could also try to search for the partition device, maybe there
> will be some interesting con
On 26/07/21 22:00, Frank Steinmetzger wrote:
> Am Sun, Jul 25, 2021 at 06:10:19PM -0500 schrieb Dale:
>
>
>> I've had more drives go bad when using USB enclosures than I've ever had
>> on IDE or (e)SATA.
>
> Interesting, I can’t really confirm such a correlation from the drives I
> have lying
Frank Steinmetzger wrote:
> Am Sun, Jul 25, 2021 at 06:10:19PM -0500 schrieb Dale:
>
>> I've tried external drives connected by USB before and hated them. Slow
>> when they do work and buggy at that.
> Theoretically, HDDs are not able to saturate USB 3. And from my observation,
> I do get their ma
Am Sun, Jul 25, 2021 at 06:10:19PM -0500 schrieb Dale:
> That's interesting. I have two different drives, can't recall but may
> be the same brand.
The actual drive in my enclusure is a Seagate, BTW.
> I've tried external drives connected by USB before and hated them. Slow
> when they do work
Frank Steinmetzger wrote:
> Am Wed, Jul 07, 2021 at 01:08:55PM -0500 schrieb Dale:
>
>> root@fireball / # blkid | grep dde669
>> /dev/mapper/8tb: LABEL="8tb-backup"
>> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
>> root@fireball / # ls /dev/disk/by-uuid | grep dde669
>
Am Wed, Jul 07, 2021 at 01:08:55PM -0500 schrieb Dale:
> root@fireball / # blkid | grep dde669
> /dev/mapper/8tb: LABEL="8tb-backup"
> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
> root@fireball / # ls /dev/disk/by-uuid | grep dde669
> 0277ff1b-2d7c-451c-ae94-f20f42dd
OK, if it could be "udev", you might want to try to check the following:
$ grep -rF "" /etc/udev/rules.d/
$ grep -rF "" /lib/udev/rules.d/
$ grep -rF "" /etc
You could also try to search for the partition device, maybe there will
be some interesting configuration files.
If you are us
Ramon Fischer wrote:
> Interesting.
>
> I have some other ideas, but this is really grasping at straws. Create
> a backup of the backup drive before doing any tests, since you have to
> move it a lot for this:
>
> 1. Connect the hard drive to a different eSATA port
> 2. Try another eSATA cabl
Interesting.
I have some other ideas, but this is really grasping at straws. Create a
backup of the backup drive before doing any tests, since you have to
move it a lot for this:
1. Connect the hard drive to a different eSATA port
2. Try another eSATA cable
3. Try to mount the hard d
Dr Rainer Woitok wrote:
> Ramon, Dale,
>
> On Tuesday, 2021-07-06 20:40:32 +0200, Ramon Fischer wrote:
>
>> This is just a guess. Maybe you have two devices with the same UUID?
>>
>> If so, you can change it with:
>>
>> $ cryptsetup --uuid="" luksUUID "/dev/sdx1"
> Good idea. But to find out
Ramon, Dale,
On Tuesday, 2021-07-06 20:40:32 +0200, Ramon Fischer wrote:
> This is just a guess. Maybe you have two devices with the same UUID?
>
> If so, you can change it with:
>
> $ cryptsetup --uuid="" luksUUID "/dev/sdx1"
Good idea. But to find out whether or not this is the cause
Ramon Fischer wrote:
> This is just a guess. Maybe you have two devices with the same UUID?
>
> If so, you can change it with:
>
> $ cryptsetup --uuid="" luksUUID "/dev/sdx1"
>
> -Ramon
>
Well, it could make sense I guess. I'd think it a very rare thing to
happen but during next backup, I'll c
This is just a guess. Maybe you have two devices with the same UUID?
If so, you can change it with:
$ cryptsetup --uuid="" luksUUID "/dev/sdx1"
-Ramon
On 05/07/2021 05:19, Dale wrote:
Dale wrote:
Dale wrote:
After staring at it a while, it hit me that lsblk is showing it as still
mounted
Dale wrote:
> Dale wrote:
>>
>> After staring at it a while, it hit me that lsblk is showing it as still
>> mounted, even tho I umounted already without error. So, I just ran the
>> umount command again. After that, it closed just fine. So, it seems to
>> be mounted twice, not once. I mount usi
Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> Dale wrote:
Dale wrote:
> Jack wrote:
>> Is it possible it was still syncing cache out to the physical drive?
>> I wonder if iotop would show any activity for that drive if that's the
>> case?
>>
>> Jack
>>
>>
>>
Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> Dale wrote:
Jack wrote:
> Is it possible it was still syncing cache out to the physical drive?
> I wonder if iotop would show any activity for that drive if that's the
> case?
>
> Jack
>
>
>
I may try that next
Dale wrote:
> Dale wrote:
>> Dale wrote:
>>> Jack wrote:
Is it possible it was still syncing cache out to the physical drive?
I wonder if iotop would show any activity for that drive if that's the
case?
Jack
>>> I may try that next time but the light had sto
Dale wrote:
> Dale wrote:
>> Jack wrote:
>>> Is it possible it was still syncing cache out to the physical drive?
>>> I wonder if iotop would show any activity for that drive if that's the
>>> case?
>>>
>>> Jack
>>>
>>>
>>>
>> I may try that next time but the light had stopped blinking for several
Dale wrote:
> Jack wrote:
>>
>> Is it possible it was still syncing cache out to the physical drive?
>> I wonder if iotop would show any activity for that drive if that's the
>> case?
>>
>> Jack
>>
>>
>>
>
> I may try that next time but the light had stopped blinking for several
> minutes. Since
If the "umount" command seems to be hanging next time, it is most likely
due to cache writebacks. You can monitor this like so:
$ watch "grep 'Dirty\|Writeback' /proc/meminfo"
-Ramon
On 15/06/2021 17:26, Dale wrote:
Jack wrote:
On 6/15/21 10:21 AM, Dale wrote:
Ramon Fischer wrote:
Hello
Jack wrote:
> On 6/15/21 10:21 AM, Dale wrote:
>> Ramon Fischer wrote:
>>> Hello Dale,
>>>
>>> this also happens to me sometimes and the culprit was an open process
>>> still accessing the hard drive. Maybe you can solve it like this:
>>>
>>> $ lsof /mnt/8tb
>>> zsh 8390 root cwd
On 6/15/21 10:21 AM, Dale wrote:
Ramon Fischer wrote:
Hello Dale,
this also happens to me sometimes and the culprit was an open process
still accessing the hard drive. Maybe you can solve it like this:
$ lsof /mnt/8tb
zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb
Ramon Fischer wrote:
> Hello Dale,
>
> this also happens to me sometimes and the culprit was an open process
> still accessing the hard drive. Maybe you can solve it like this:
>
> $ lsof /mnt/8tb
> zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb
> $ kill 8390
> $ lso
Hello Dale,
this also happens to me sometimes and the culprit was an open process
still accessing the hard drive. Maybe you can solve it like this:
$ lsof /mnt/8tb
zsh 8390 root cwd DIR 253,2 4096 27787265 /mnt/8tb
$ kill 8390
$ lsof /mnt/8tb
After that, you should
Howdy,
As some may recall, I use external drives as backups. They are
encrypted and I use cryptsetup to open and close them. Open works fine
but close gives me trouble at times. It doesn't always do this but it
does it more often than not. It's getting annoying.
Drive one. It's a 6TB drive
27 matches
Mail list logo
