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 stopped blinking for several >>> minutes. Since it is a SMR drive, I always leave it running until I >>> can't feel the heads bumping around. I don't think it would be that >>> but, it's worth a try. It may lead to something. >>> >>> Will update when it does it again. >>> >>> Thanks. >>> >>> Dale >>> >>> :-) :-) >>> >> I had to wait until I was doing backups again to try anything. The 6TB >> drive did fine. The 8TB drive is giving the in use error. The drive is >> unmounted but iotop didn't show anything and the light isn't blinking >> either. I'd think if it was flushing cache the light would flash and it >> would not umount. >> >> I tried the udev-trigger trick but it didn't work. I don't know how >> long it will stay 'in use' so if anyone has ideas, think and type fast. >> If not, may have to wait until next time to try again. >> >> Dale >> >> :-) :-) >> > > Some more info: > > > root@fireball / # lvs > LV VG Attr LSize Pool Origin Data% Meta% Move Log > Cpy%Sync Convert > Home2 Home2 -wi-ao---- > <12.74t > swap OS -wi-ao---- > 12.00g > usr OS -wi-ao---- > 35.00g > var OS -wi-ao---- > 52.00g > backup backup -wi-ao---- > 698.63g > root@fireball / # vgs > VG #PV #LV #SN Attr VSize VFree > Home2 2 1 0 wz--n- <12.74t 0 > OS 1 3 0 wz--n- <124.46g <25.46g > backup 1 1 0 wz--n- 698.63g 0 > root@fireball / # pvs > PV VG Fmt Attr PSize PFree > /dev/sda7 OS lvm2 a-- <124.46g <25.46g > /dev/sdb1 Home2 lvm2 a-- <5.46t 0 > /dev/sdc1 Home2 lvm2 a-- <7.28t 0 > /dev/sdd1 backup lvm2 a-- 698.63g 0 > root@fireball / # cryptsetup close 8tb > Device 8tb is still in use. > root@fireball / # > > > As you can see, lvm doesn't even show the device but it is still under > /dev as tho it is available. Weird. > > I found this but at the end, the command doesn't help me. I'm not sure > why. It does talk about using LUKS on top of LVM causing this problem. > Since the fix doesn't work, is this a different problem?? > > > https://linux-blog.anracom.com/tag/device-still-in-use/ > > > I've tried every command I can find and it still shows busy. I even > restarted udev and lvm. Still busy. > > Ideas? > > Dale > > :-) :-) >
Found another tidbit of info that may shed some light on this problem. I'm not sure what it means tho. root@fireball / # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT <<<SNIP>>> sdj 8:144 1 7.3T 0 disk └─sdj1 8:145 1 7.3T 0 part └─8tb 254:5 0 7.3T 0 crypt /mnt/8tb sr0 11:0 1 1024M 0 rom root@fireball / # So, something called crypt seems to have it open. Now how do I tell it to go away? Hmmmm. Then I came up with this idea: root@fireball / # ps aux | grep crypt root 493 0.0 0.0 0 0 ? I< Jun13 0:00 [cryptd] root 11509 0.0 0.0 7728 2448 pts/2 S+ 00:30 0:00 grep --colour=auto crypt root 23667 0.0 0.0 0 0 ? I< Jun20 0:00 [kcryptd_io/254:] root 23668 0.0 0.0 0 0 ? I< Jun20 0:00 [kcryptd/254:5] root 23669 0.0 0.0 0 0 ? S Jun20 0:00 [dmcrypt_write/2] root@fireball / # So kcryptd is the offender it seems since it matches MAJ:MIN info. I assume that is kernel related not KDE. Can I just kill that process? Will it do damage if I kill it or is there a better way? Dale :-) :-)
