2

I have a hard drive from a Javelin S4 (similar to Promise NS4600N) enclosure that was setup as a single disk RAID0 that I have tried adding to my Linux Ubuntu server (14.x) generic "Linux 3.13.0-49-generic" I believe the FS type is xfs based on what I've read. I also have a disk from a Promise NS4300N which I was able to add (ext3) no issues, same single disk RAID0 format.

When ever I try to mount the XFS device I get the error "Function not implemented".

fdisk -l (only relative items provided):

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

[...]

Disk /dev/mapper/vg002-lv001: 1999.0 GB, 1998950760448 bytes
255 heads, 63 sectors/track, 243025 cylinders, total 3904200704 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/vg002-lv001 doesn't contain a valid partition table

This info is the same as the ext3 device which mounts fine.

When I do any of the following:

sudo mount -t xfs /dev/vg002/lv001 /hdd/volume2
sudo mount -t xfs /dev/mapper/vg002-lv001
sudo mount /dev/vg002/lv001 /hdd/volume2
sudo mount /dev/mapper/vg002-lv001

I just get Function not implemented.

I have installed xfsprogs and xfsdump

I have tried options in both Ubuntu server and Ubuntu desktop

I have run xfs-repair, first as the -n and next without the no action switch:

sudo xfs_repair -v /dev/mapper/vg002-lv001
Phase 1 - find and verify superblock...
        - block cache size set to 758408 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 195328 tail block 195328
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
Note - quota info will be regenerated on next quota mount.

        XFS_REPAIR Summary    Wed Aug 19 09:45:12 2015

Phase           Start           End             Duration
Phase 1:        08/19 09:44:51  08/19 09:44:52  1 second
Phase 2:        08/19 09:44:52  08/19 09:45:02  10 seconds
Phase 3:        08/19 09:45:02  08/19 09:45:10  8 seconds
Phase 4:        08/19 09:45:10  08/19 09:45:11  1 second
Phase 5:        08/19 09:45:11  08/19 09:45:11
Phase 6:        08/19 09:45:11  08/19 09:45:11
Phase 7:        08/19 09:45:11  08/19 09:45:11

Total run time: 20 seconds

I have done vgscan

Reading all physical volumes.  This may take a while...
  Found volume group "vg002" using metadata type lvm2

[...]

I have verified that xfs is supporting in /procs/filesystems and that it does not have nodev in it (don't have /etc/filesystems)

I believe the HDD block sizes are 4096 and have done a getconf PAGE_SIZE with a return of 4096

a dmesg | tail yields:

[ 1631.686429] XFS (dm-0): Corruption detected. Unmount and run xfs_repair
[ 1631.686433] XFS (dm-0): SB validate failed with error 38.
[31648.998141] XFS (dm-0): unknown mount option [csize].
[31665.514229] XFS (dm-0): unknown mount option [csize].

I have also ran this command on both hard disks from the two different NASs:

sudo file -s /dev/sda
/dev/sda: LVM2 PV (Linux Logical Volume Manager), UUID: KNAIIR-rtHE-ucTO-cWT4-Zke0-7NVX-7WNpD0, size: 2000331800576

sudo file -s /dev/sdc
/dev/sdc: LVM2 PV (Linux Logical Volume Manager), UUID: ANxiVX-4s1T-dtNj-vCGA-xNGE-p39E-UP0bHc, size: 1999999991808

And still more data on the device:

sudo lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg002/lv001
  LV Name                lv001
  VG Name                vg002
  LV UUID                cOl9oX-IoNh-azhW-cnxS-USa6-LpV6-sI0RKQ
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              available
  # open                 0
  LV Size                1.82 TiB
  Current LE             476587
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

  --- Logical volume ---
  LV Path                /dev/vg002/nsswap
  LV Name                nsswap
  VG Name                vg002
  LV UUID                qidCbH-TlD0-oXPB-cb36-tPZy-3anI-7gcC2Q
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              available
  # open                 0
  LV Size                512.00 MiB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

With the lvdisplay command, I do notice that it has a nswap entity that the other ext3 device didn't have. Not sure if that means anything (sorry, bit of a noob, or at least, not well versed in managing Linux infrastructure).

Anyone have any thoughts on what I haven't tried yet? Suggestions? The data is fine, I just would like to be able to transfer the data from disk to disk rather than have to do it over the network - NAS > workstation > NAS - takes a long time.

Thanks

  • It may be a block size issue I think: can you add the output of xfs_info /dev/mapper/vg002-lv001 please? – steeldriver Aug 19 '15 at 17:59
  • 'xfs_info: /dev/mapper/vg002-lv001 is not a mounted XFS filesystem' – DeanoDino Aug 19 '15 at 18:11
  • Oops I didn't realize it needed to be mounted for xfs_info to work: can you try sudo file -sL /dev/mapper/vg002-lv001 instead? I think that should include a blksz field – steeldriver Aug 19 '15 at 18:22
  • /dev/mapper/vg002-lv001: SGI XFS filesystem data (blksz 65536, inosz 256, v2 dirs). So that's the problem it's 64K size :( So I need to change my pagesize config to 64K? – DeanoDino Aug 19 '15 at 18:27
  • I think block size likely is the issue, but I don't have any suggestion as to what you might try: see serverfault.com/questions/246640/…. With large-block ext filesystems there is a workaround using fuse, but I don't know if the same applies with xfs. – steeldriver Aug 19 '15 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.