mounted usb partition is shown as loop0

[dankamongmen]

I've got /dev/sdo1, a partition on my usb device, mounted at /media/usb.

│n/a               ext4  550fc6fe-e22e-4cc5-b066-f81343f772e0  32.97G loop0  │  
│ /media/usb rw,relatime                                                     │─╮
│                                                 

why loop0? it's /dev/sdo1. i mounted it manually.

[dankamongmen]

same in growlight-readline:

n/a               vfat  78F1-BDDB                            nvme0n   1.07G
 /boot/efi rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
n/a               ext4  939be09a-b63d-403c-996a-8b9866313fbb md127  104.03G
 / rw,noatime,errors=remount-ro
n/a               ext4  939be09a-b63d-403c-996a-8b9866313fbb md127  104.03G
 /var/lib/schroot/union/underlay/debcargo-unstable-amd64-sbuild-3c4ab350-6d13-4643-a108-86fd48838b81 rw,noatime,errors=remount-ro
n/a               ext4  939be09a-b63d-403c-996a-8b9866313fbb md127  104.03G
 /run/schroot/mount/debcargo-unstable-amd64-sbuild-3c4ab350-6d13-4643-a108-86fd48838b81/build rw,noatime,errors=remount-ro
n/a               ext4  550fc6fe-e22e-4cc5-b066-f81343f772e0 loop0   32.97G
 /media/usb rw,relatime
zhomez            zfs   7730803059136165722                  zhomez 778.26G
 /home rw,noatime,xattr,noacl
chungus           zfs   7155547617804506101                  chungu  79.36T
 /media/chungus ro,noatime,xattr,noacl

in reality:

[schwarzgerat](0) $ mount | grep usb
/dev/sdo1 on /media/usb type ext4 (rw,relatime)
[schwarzgerat](0) $ mount | grep loop
[schwarzgerat](1) $ 

[dankamongmen]

huh, /proc/mounts does indicate /dev/loop0(!)

[schwarzgerat](1) $ cat /proc/mounts  | grep loop
/dev/loop0 /media/usb ext4 rw,relatime 0 0
[schwarzgerat](0) $ cat /proc/mounts  | grep usb
/dev/loop0 /media/usb ext4 rw,relatime 0 0
[schwarzgerat](0) $ cat /proc/mounts  | grep sdo
[schwarzgerat](1) $ 

what the hell?

[dankamongmen]

hrmmm, from dmesg:

[32761.292965]  sdo: sdo1
[32761.375933]  sdo: sdo1
[32772.532361]  sdo: sdo1
[32774.802556]  sdo: sdo1
[32780.976056] loop: module loaded
[32781.016572] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

the worm turns...

[dankamongmen]

we can chase down the /dev/loop0 and see that it is indeed associated with /dev/sdo1:

[schwarzgerat](127) $ losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0         0      0         1  0 /dev/sdo1   0     512
[schwarzgerat](0) $ 

but why is loop0 getting involved at all? :(

[dankamongmen]

[schwarzgerat](127) $ cat /sys/block/loop0/loop/backing_file 
/dev/sdo1
[schwarzgerat](0) $ 

[dankamongmen]

and indeed, we seem to know this:

[growlight](0)> blockdev
Device     Model             Rev   Bytes PSect Flags Table WWN              PHY 
sdn        ST12000NM0007-2A SN03  12.00T 4096B ✔OW⚠. gpt   5000c500a5c0e61d SAT3
sdm        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b49867e5 SAT3
sdb        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b56936d2 SAT3
sdd        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b3f4afb4 SAT3
sdf        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b56a29d4 SAT3
sde        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b5685ea4 SAT3
sdc        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b4104bf5 SAT3
sdg        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b1c2c393 SAT3
sda        ST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b4984eca SAT3
sr0        iHBS112   2      CL0F   1.07G  512B UO... none  n/a              PATA
nvme0n1    WDS100T3X0C-00SJ  n/a   1.00T  512B ✔.... gpt   1908E1805012     NVMe
nvme1n1    WDS100T3X0C-00SJ  n/a   1.00T  512B ✔.... gpt   1908E1801188     NVMe
nvme2n1    INTEL MEMPEK1W01  n/a  14.40G  512B ✔.... gpt   PHBT729201SR016D NVMe
md127      Linux mdadm       1.2 106.23G  512B VM... none  root             NVMe
loop5      n/a               n/a    0.00  512B VO... none  n/a              n/a 
loop4      n/a               n/a    0.00  512B VO... none  n/a              n/a 
loop3      n/a               n/a    0.00  512B VO... none  n/a              n/a 
loop7      n/a               n/a    0.00  512B VO... none  n/a              n/a 
loop0      /dev/sdo1         n/a   6.99G  512B VO... none  n/a              n/a 
loop2      n/a               n/a    0.00  512B VO... none  n/a              n/a 
loop6      n/a               n/a    0.00  512B VO... none  n/a              n/a 
loop1      n/a               n/a    0.00  512B VO... none  n/a              n/a 
zhomez     LLNL ZoL         5000 884.76M 4096B VZ... spa   n/a              ?   
chungus    LLNL ZoL         5000 107.99M  512B VZ... spa   n/a              ?  

[dankamongmen]

/proc/$$/mountinfo also shows /dev/loop0. strace of mount shows it reading loop/backing_file.

[dankamongmen]

OK, I finally figured this out. From the mount(8) man page:

       The mount command automatically creates a loop device  from  a  regular
       file  if  a filesystem type is not specified or the filesystem is known
       for libblkid, for example:

              mount /tmp/disk.img /mnt

              mount -t ext4 /tmp/disk.img /mnt

and if we go and look at my /dev/sdo1, what do we see?

[schwarzgerat](0) $ ls -l /dev/sdo1
-rw-r--r-- 1 root root 6986502144 2020-11-30 12:40 /dev/sdo1
[schwarzgerat](0) $ 

it's a file, not a device! so that explains everything. i blew it away at some point with an erroneous dd.

So I think the problem discussed in #127 is still a valid one -- we ought be able to see how an underlying device is mounted, even through a loop device. But this was never an underlying device; it was an underlying file. We were just confused because the name of said file was /dev/sdo1 (which incidentally prevented the true device from being created).

Maybe we ought differentiate between a backing block device and a backing file. We definitely ought not create a virtual device named after the file, but I don't think we were.

This, of course, was also why we weren't seeing a filesystem on the real first partition of the real /dev/sdo -- there wasn't one. There was a filesystem on a file named /dev/sdo1 only. Madness!

Closing this.