That sounds like it would cause a problem. Any reason for that?
Redundancy/failover and performance. Before I did that, the single SAS connection to the HBA was my bottleneck and single point of failure. Now it’s neither.
FreeNAS automagically takes advantage of it. Linux appears to throw a fit but only on boot. I wonder if the multi path kernel module would address it.
Correction: I think it’s not technically “multipath” but “dual link”.
I guess that’s fair. I’ve never used that solution. We’ve always done multiple copies.
1 Like
That’s it. I don’t think I have anything else to try…
In Ubuntu 16.04 I can’t get past:
ext4magic:
Error 2133571465 while reading block bitmap
extundelete:
Loading filesystem metadata ... 229376 groups loaded.
Loading journal descriptors ... 25182 descriptors loaded.
*** Error in `extundelete': double free or corruption (!prev): 0x0000000002526910 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb5dc2c17e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fb5dc2ca37a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fb5dc2ce53c]
extundelete[0x40d6de]
extundelete[0x4104e4]
extundelete[0x4047d0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb5dc26a830]
extundelete[0x404c8f]
======= Memory map: ========
00400000-0041d000 r-xp 00000000 00:1a 91532 /usr/bin/extundelete
0061c000-0061d000 r--p 0001c000 00:1a 91532 /usr/bin/extundelete
0061d000-0061e000 rw-p 0001d000 00:1a 91532 /usr/bin/extundelete
0061e000-0061f000 rw-p 00000000 00:00 0
0250b000-0275b000 rw-p 00000000 00:00 0 [heap]
7fb590000000-7fb590021000 rw-p 00000000 00:00 0
7fb590021000-7fb594000000 ---p 00000000 00:00 0
7fb594f21000-7fb5dbd24000 rw-p 00000000 00:00 0
7fb5dbd24000-7fb5dbe2c000 r-xp 00000000 00:1a 50 /lib/x86_64-linux-gnu/libm-2.23.so
7fb5dbe2c000-7fb5dc02b000 ---p 00108000 00:1a 50 /lib/x86_64-linux-gnu/libm-2.23.so
7fb5dc02b000-7fb5dc02c000 r--p 00107000 00:1a 50 /lib/x86_64-linux-gnu/libm-2.23.so
7fb5dc02c000-7fb5dc02d000 rw-p 00108000 00:1a 50 /lib/x86_64-linux-gnu/libm-2.23.so
7fb5dc02d000-7fb5dc045000 r-xp 00000000 00:1a 53 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fb5dc045000-7fb5dc244000 ---p 00018000 00:1a 53 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fb5dc244000-7fb5dc245000 r--p 00017000 00:1a 53 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fb5dc245000-7fb5dc246000 rw-p 00018000 00:1a 53 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fb5dc246000-7fb5dc24a000 rw-p 00000000 00:00 0
7fb5dc24a000-7fb5dc40a000 r-xp 00000000 00:1a 28 /lib/x86_64-linux-gnu/libc-2.23.so
7fb5dc40a000-7fb5dc60a000 ---p 001c0000 00:1a 28 /lib/x86_64-linux-gnu/libc-2.23.so
7fb5dc60a000-7fb5dc60e000 r--p 001c0000 00:1a 28 /lib/x86_64-linux-gnu/libc-2.23.so
7fb5dc60e000-7fb5dc610000 rw-p 001c4000 00:1a 28 /lib/x86_64-linux-gnu/libc-2.23.so
7fb5dc610000-7fb5dc614000 rw-p 00000000 00:00 0
7fb5dc614000-7fb5dc62a000 r-xp 00000000 00:1a 1301 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fb5dc62a000-7fb5dc829000 ---p 00016000 00:1a 1301 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fb5dc829000-7fb5dc82a000 rw-p 00015000 00:1a 1301 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fb5dc82a000-7fb5dc99c000 r-xp 00000000 00:1a 1300 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7fb5dc99c000-7fb5dcb9c000 ---p 00172000 00:1a 1300 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7fb5dcb9c000-7fb5dcba6000 r--p 00172000 00:1a 1300 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7fb5dcba6000-7fb5dcba8000 rw-p 0017c000 00:1a 1300 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7fb5dcba8000-7fb5dcbac000 rw-p 00000000 00:00 0
7fb5dcbac000-7fb5dcbec000 r-xp 00000000 00:1a 2000 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7fb5dcbec000-7fb5dcdec000 ---p 00040000 00:1a 2000 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7fb5dcdec000-7fb5dcded000 r--p 00040000 00:1a 2000 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7fb5dcded000-7fb5dcdee000 rw-p 00041000 00:1a 2000 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7fb5dcdee000-7fb5dcdf1000 r-xp 00000000 00:1a 2038 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7fb5dcdf1000-7fb5dcff0000 ---p 00003000 00:1a 2038 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7fb5dcff0000-7fb5dcff1000 r--p 00002000 00:1a 2038 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7fb5dcff1000-7fb5dcff2000 rw-p 00003000 00:1a 2038 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7fb5dcff2000-7fb5dd018000 r-xp 00000000 00:1a 24 /lib/x86_64-linux-gnu/ld-2.23.so
7fb5dd065000-7fb5dd126000 rw-p 00000000 00:00 0
7fb5dd1b8000-7fb5dd200000 rw-p 00000000 00:00 0
7fb5dd216000-7fb5dd217000 rw-p 00000000 00:00 0
7fb5dd217000-7fb5dd218000 r--p 00025000 00:1a 24 /lib/x86_64-linux-gnu/ld-2.23.so
7fb5dd218000-7fb5dd219000 rw-p 00026000 00:1a 24 /lib/x86_64-linux-gnu/ld-2.23.so
7fb5dd219000-7fb5dd21a000 rw-p 00000000 00:00 0
7ffd721ac000-7ffd721cd000 rw-p 00000000 00:00 0 [stack]
7ffd721dd000-7ffd721e0000 r--p 00000000 00:00 0 [vvar]
7ffd721e0000-7ffd721e2000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
photorec:
Ran for 24 hours, recovered thousands of file fragments. Nothing useable larger than a thumbnail image.
foremost:
Limited file type support.
If anyone has any ideas or knows how to get around the errors with the ext* recovery programs, please let me know…
Superblock
NOTICE: Extended attributes are not restored.
WARNING: Unknown file system feature: EXT2_FEATURE_INCOMPAT_META_BG
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible. You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)
y
Inodes count: 1879048192
Blocks count: 3221225472
Reserved blocks count: 131072
Free blocks count: 1717334077
Free inodes count: 1878769323
First Data Block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 1
Inodes per group: 8192
Mount time: 1541784681
Write time: 1541784681
Mount count: 15
Maximal mount count: -1
Magic signature: 61267
File system state: 1
Behaviour when detecting errors: 1
minor revision level: 0
time of last check: 1541434003
max. time between checks: 0
OS: 0
Revision level: 1
Default uid for reserved blocks: 0
Default gid for reserved blocks: 0
First non-reserved inode: 11
size of inode structure: 256
block group # of this superblock: 0
compatible feature set: 12
incompatible feature set: 726
readonly-compatible feature set: 123
128-bit uuid for volume: 13b1efc0b4b7467cb258d16deea1be2f
For compression: 0
Nr to preallocate for dirs: 0
Per group table for online growth: 0
uuid of journal superblock: 00000000000000000000000000000000
inode number of journal file: 8
device number of journal file: 0
start of list of inodes to delete: 814481515
HTREE hash seed: f9bdd9abb5497c4b73cdc7939d3c4d21
Default hash version to use: 1
Default type of journal backup: 1
First metablock group: 2560
When the filesystem was created: 1501957812
Compatible feature set: HAS_JOURNAL EXT_ATTR
Incompatible feature set: FILETYPE RECOVER META_BG
Read only compatible feature set: SPARSE_SUPER LARGE_FILE
You’re at the end of my experience. Wish I could help more. 
1 Like
Does a filesystem on an logical volume have an offset?
Uh, typically no. You might offset your LVs partition, if you made a partition on it. (not recommended)
1 Like
Cool, that’s what I thought.
I’m trying photorec again with manually entered block size and offset. If those were wrong, that could explain the terrible results I had last time.
1 Like
Try just recovering half of the raid 10
1 Like
RAID was circumvented by copying the filesystem into an image file on another system. I’ve retitled this thread to reflect how it’s developed.
Anyone know how to deal with .gz files that might have extra data at the end? I have a bunch from photorec. Most are probably corrupted, but photorec will also produce files that have a bunch of garbage appended to the end, but are otherwise good.
1 Like
Can you give an example file? I’d be happy to do some work on one and let you know my results, but I understand if you can’t do that. How big of a GZ file are we talking here?
Nvm, please disregard…
gunzip: test.gz: trailing garbage ignored