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
xfs_info /dev/mapper/vg002-lv001please? – steeldriver Aug 19 '15 at 17:59xfs_infoto work: can you trysudo file -sL /dev/mapper/vg002-lv001instead? I think that should include ablkszfield – steeldriver Aug 19 '15 at 18:22fuse, but I don't know if the same applies with xfs. – steeldriver Aug 19 '15 at 18:32