Jump to content

  • 4Kn devices formatted with xfs, Unraid reports the device as 512B at mkfs time and that's what xfs uses

    onyxdrew

    By onyxdrew

      • Minor

    Since these devices are 4K and the file system is created as 512B, you are unable to mount these file systems outside of the unraid array.

     

    If I just click mount via unassigned devices:

    Apr 29 09:25:42 Tower unassigned.devices: Mount drive command: /sbin/mount -o rw,noatime,nodiratime '/dev/mapper/HGST_HUH721010AL4200_direct' '/mnt/disks/HGST_HUH721010AL4200_direct'
    Apr 29 09:25:42 Tower kernel: XFS (dm-8): device supports 4096 byte sectors (not 512

     

    Here is me doing it manually in console on temp server to test this:

    root@Tower:~# /usr/sbin/cryptsetup luksOpen /dev/sdd1 HGST_HUH721010AL4200_direct
    Enter passphrase for /dev/sdd1: PASSWORD ENTERED HERE

    root@Tower:~# mkdir /tmp/test
    root@Tower:~# /sbin/mount -o rw,noatime,nodiratime /dev/mapper/HGST_HUH721010AL4200_direct /tmp/test
    mount: /tmp/test: mount(2) system call failed: Function not implemented.
    root@Tower:~# tail -5 /var/log/syslog 
    Apr 29 09:25:42 Tower kernel: XFS (dm-8): device supports 4096 byte sectors (not 512)
    Apr 29 09:25:42 Tower unassigned.devices: Mount of 'HGST_HUH721010AL4200_direct' failed: 'mount: /mnt/disks/HGST_HUH721010AL4200_direct: mount(2) system call failed: Function not implemented. '
    Apr 29 09:25:42 Tower unassigned.devices: Partition 'HGST_HUH721010AL4200_direct' cannot be mounted.
    Apr 29 09:27:48 Tower kernel: XFS (dm-8): device supports 4096 byte sectors (not 512)

     

    Drive in question:

    root@Tower:~# blockdev --report /dev/sdd*
    RO    RA   SSZ   BSZ   StartSec            Size   Device
    rw   256  4096  4096          0  10000831348736   /dev/sdd
    rw   256  4096  4096         64  10000831295488   /dev/sdd1

     

    A few other devices that were from the same original array:

    root@Tower:~# blockdev --report /dev/md*
    RO    RA   SSZ   BSZ   StartSec            Size   Device
    rw   256   512  4096          0  10000831295488   /dev/md1
    rw   256   512  4096          0  10000831295488   /dev/md2
    rw   256   512  4096          0  10000831295488   /dev/md3

     

    That device:

    image.thumb.png.225f20067f778ef5647fe40d79e54fbb.png

     

    I built a brand new server and this is what I see:

    O    RA   SSZ   BSZ   StartSec            Size   Device
    rw   256   512   512          0     32080200192   /dev/sdb
    rw   256   512   512       2048     32079151616   /dev/sdb1
     

    O    RA   SSZ   BSZ   StartSec            Size   Device
    rw   256   512  4096          0  18000207884288   /dev/md1

     

     

     

     

    See the thread that triggered this bug report:

     

    Go to reports Stable Releases

    User Feedback

    Recommended Comments

    nick5429

    Kind of ridiculous that this wasn't addressed at all, and the moderator comments in the linked thread amount to "well, sorry -- no way to recover this; but here's the command to reformat it [and destroy your data]!". The ability to mount individual unraid disks on another system was a core advertised selling point in case of some sort of system crash/malfunction.

     

    Anyway. I encountered this upon intentionally removing an xfs drive containing data from my working unraid array, then intended to mount it for further usage.

     

     

    A regular mount command yielded 

    # mount -t xfs  /dev/sdd1 /tmp/is-disk6/

mount: /tmp/is-disk6: mount(2) system call failed: Function not implemented.
       dmesg(1) may have more information after failed mount system call.

     

    from dmesg [however, this is misleading]: 

    [434721.989672] XFS (sdd1): device supports 4096 byte sectors (not 512)

     

    I vaguely recall something in earlier unraid versions ~10+ years ago(?) about the partition start offset being located differently for certain disks.  I'm going to walk through this, so that someone can repeat for other filesystems if needed.  When I instead was trying to mount the image I had made of this disk, we get a more meaningful message: 

    [435447.749797] XFS (loop4): Invalid superblock magic number

     

    Well then, let's go looking for the superblock! (the xfs superblock appears to begin with the characters "XFSB"; see https://righteousit.com/2018/05/21/xfs-part-1-superblock/ ) 

    # head /dev/sdd | xxd | grep XFSB
00008000: 5846 5342 0000 1000 0000 0000 7470 2549  XFSB........tp%I

     

    So the superblock is at position hex 8000 on the disk [note sdd, not sdd1]. Hex 8000 is 32768. Let's try to mount it again with that knowledge: 

    # mount -t xfs -o offset=32768 /dev/sdd /tmp/is-disk6/

     

    The resulting syslog/dmesg: 

    [437166.745404] loop4: detected capacity change from 0 to 15628053104
[437166.747384] XFS (loop4): Mounting V5 Filesystem
[437166.816444] XFS (loop4): Ending clean mount
[437166.817210] xfs filesystem being mounted at /tmp/is-disk6 supports timestamps until 2038 (0x7fffffff)

    And now it works as expected to browse the drive

     

     

    I don't know what superblock offset xfs typically expects, but you can also mount the "partition" by giving it offset=0: 

    # mount -t xfs -o offset=0 /dev/sdd1 /tmp/is-disk6/

     

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.

    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.

×
×
  • Create New...