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.