Issue after upgrading lacie firmware

[turmeric]

Thank you fvdw!

From what I read, running

Code: Select all

# xfs_repair /dev/md4

is basically what is the standardprocedure and did not find any information about it destroying data.

So, I was brave enough to run it. After approx 25 minutes and several

Code: Select all

...found candidate secondary superblock...
error reading superblock 175 -- seek to offset 6012942745600 failed
unable to verify superblock, continuing...
found candidate secondary superblock...
error reading superblock 175 -- seek to offset 6012942745600 failed
unable to verify superblock, continuing...


I got

Code: Select all

...found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock

fatal error -- couldn't allocate block map, size = 8388608


I understand that I'm out of memory to execute the repair. And I fear I understood that there is no way to assign more memory...?

Would anybody have an idea what is next step? Data recovery consultants? Accidentially any good contacts in the Zurich area?

Tnx,
turmeric

[fvdw]

I remember that we have seen that problem before. You need to use the -m option of xfs_repair to limit memory usage, seems 800 was good value to use for that option

[turmeric]

Good idea :thumbup

So I try with

Code: Select all

xfs_repair -m 800 /dev/md4
Phase 1 - find and verify superblock...

fatal error -- couldn't allocate block map, size = 8388608


Consequently I adapt to

Code: Select all

xfs_repair -m 700 /dev/md4
Phase 1 - find and verify superblock...
Required memory for repair is greater that the maximum specified with the -m option. Please increase it to at least 746.


and then to

Code: Select all

xfs_repair -m 747 /dev/md4
Phase 1 - find and verify superblock...

fatal error -- couldn't allocate block map, size = 8388608


Unfortunately, the 5Big2 seems to weak for it :sob

From what I read, possibility to connect the disks directly to a linux machine with enough memory to perform the repair. However, do not have such a setup at hand

[fvdw]

Did you try 800 or 900?. Need to find that topic were this option was used. I still find it difficult to believe that xfs repair won't run because of memory shortage. The standalone kernel does't have a swap maybe that is causing this problem. This we could solve if on of your disk has a partition that we could use for that. A command like fdisk -l should list all partion tables. If the disks have a gpt partition table then gdisk must be used.

Ps To run linux on pc with these disk you need a mobo with 5 sata ports or 5 usb-sata adapters and for instance a knoppix cd

[fvdw]

I found this,

try running:

# xfs_repair -m 1 -vv <device>

And it will tell you how much memory you need to repair the
filesystem. Note that this is only a rough estimate - it may be
quite a bit more than the amount specified depending on the state
and contents of the filesystem...

I also read that large file system may need several gig's of ram

[turmeric]

when I run with this command, I get

Code: Select all

xfs_repair -m 1 -vv /dev/md4
Phase 1 - find and verify superblock...
        - max_mem = 1024, icount = 64, imem = 0, dblock = 1463627520, dmem = 714661
Required memory for repair is greater that the maximum specified with the -m option. Please increase it to at least 746.


Not sure though what to read out of the output - the 746 MB I got.

However, when you say several GB of RAM, then connecting to another computer seems to be necessary...

[fvdw]

I am not on my pc but on a smartphone. Did you verify that the value of -m option means mem size in MB?

If so yes then this exceeds the ram size of the 5big2, it has 512MB. Setting up a swap of another 512MB may solve this. We could also try to use an usb stick for this. In an hour I will be on my pc

[turmeric]

I am not on my pc but on a smartphone. Did you verify that the value of -m option means mem size in MB?

If so yes then this exceeds the ram size of the 5big2, it has 512MB. Setting up a swap of another 512MB may solve this. We could also try to use an usb stick for this. In an hour I will be on my pc

thanks for your great support here fvdw. Indeed the -m option is meant in MB.

If possible with USB stick or Swap would of course be fantastic. But no worries - tomorrow will be good as well ;)

[fvdw]

I made a trial on my 5big2. I used an usb stick of 1 GB and was able to make a swap of 1GB

I loaded the standalone kernel from fvdw-sl console 5.5.

The usb device was recognized as /dev/sej

To use it as swap I deleted all partitions on it and made a one new partition
I did this

Code: Select all

fdisk /dev/sej

To delete existing partitions use within fdisk the command "d" (without quites)
Delete all partitions if there are more then 1 (you can list the partition table with command "p"
When it is empty create a primary partition using commands "n" and choose p accept the default start and end cylinder the partition will then get total size of your usb stick.
Before writing the new table change the partition id to swap using the command "t" and as hex value 82.
Write the new table to the stick using the command "w"
If you don't do this last step then the new table is not written to the stick.

Check if everything went well
fdisk -l should list /dev/sej like this

Code: Select all

Disk /dev/sej: 1040 MB, 1040187392 bytes
32 heads, 62 sectors/track, 1024 cylinders
Units = cylinders of 1984 * 512 = 1015808 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sej1               1        1024     1015777  82 Linux swap


initialize the swap

Code: Select all

mkswap /dev/sej1

Switch on the swap

Code: Select all

swapon /dev/sej1

check if swap is available

Code: Select all

oot@fvdw-sta-kirkwood:/ # free
             total         used         free       shared      buffers
Mem:        511936         9340       502596            0            4
-/+ buffers:               9336       502600
Swap:      1015804            0      1015804
root@fvdw-sta-kirkwood:/ #

or

Code: Select all

root@fvdw-sta-kirkwood:/ # cat /proc/meminfo
MemTotal:         511936 kB
MemFree:          502604 kB
MemAvailable:     499120 kB
Buffers:               4 kB
Cached:             3616 kB
SwapCached:            0 kB
Active:             1504 kB
Inactive:           2320 kB
Active(anon):       1504 kB
Inactive(anon):     2316 kB
Active(file):          0 kB
Inactive(file):        4 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1015804 kB
SwapFree:        1015804 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:           228 kB
Mapped:              648 kB
Shmem:              3616 kB
Slab:               2728 kB
SReclaimable:        156 kB
SUnreclaim:         2572 kB
KernelStack:         408 kB
PageTables:           52 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1271772 kB
Committed_AS:       4780 kB
VmallocTotal:     499712 kB
VmallocUsed:        5588 kB
VmallocChunk:     493408 kB
root@fvdw-sta-kirkwood:/ #

Hopefully now the xfs_repair command will be able to run :whistle

edit---from what I read on the Internet on memory shortage with xfs_repair it seems our swap trick should solve this problem. of course you can use a bigger usb stick as well if 1 GB is not sufficient.
I will also look if I can compile a newer version of xfs-repair there seesm to be some memory usage improvements

--edit-2, attached the newest version of xfs_repair 3.2.3
It also needs the mini glibc stuff

---edit---
With the last version 6.0, no need to upload xfs_repair manually. Use a new option with fvdw-programs menu :
* run on the telnet window the command: fvdw-sl-programs
(then a menu will appear)
* select "Upload and extract glibc mini and tools"

Jocko

[turmeric]

Good morning fvdw,

thank you very much for these instructions. Following it allowed to create the swap and it is shown

Code: Select all

cat /proc/meminfo
MemTotal:         511936 kB
MemFree:          490792 kB
MemAvailable:     487392 kB
Buffers:             124 kB
Cached:            10596 kB
SwapCached:            0 kB
Active:             5928 kB
Inactive:           5004 kB
Active(anon):       5844 kB
Inactive(anon):     4964 kB
Active(file):         84 kB
Inactive(file):       40 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1019740 kB
SwapFree:        1019740 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:           236 kB
Mapped:              656 kB
Shmem:             10596 kB
Slab:               3108 kB
SReclaimable:        204 kB
SUnreclaim:         2904 kB
KernelStack:         440 kB
PageTables:           52 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1275708 kB
Committed_AS:      11764 kB
VmallocTotal:     499712 kB
VmallocUsed:        5584 kB
VmallocChunk:     493628 kB


So I initiate the xfs_repair...

Code: Select all

 xfs_repair /dev/md4
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Memory available for repair (374MB) may not be sufficient.
At least 746MB is needed to repair this filesystem efficiently
If repair fails due to lack of memory, please
turn prefetching off (-P) to reduce the memory footprint.
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.


So it seems that xfs_repair, even though now the memory with swap should be sufficient, does not want to use it... Or do I somehow need to assign the swap to the xfs_repair?