xfsprogs for standalone kernel

[wvwaard]

Dear fvdw and jocko (sorry if i type this incorrect doing it from memory),

Thank you for writing kernels, tools etc to make life easier for
admins like me having sh...t with there NAS equipment.
This time being a 5big2. Have the same problem as another poster , shares gone etc.

First let me startoff with a tip. When you use the fvdw-sl utils and cannot get
the root prompt in the telnet session? It's propably that you have a laptop, switch and
the lacie connected on a single network without DHCP. Just run the system once with
the "standalone" option , then do it again but this time with an altered setup of the TFTPD.
Setup DHCP on the TFTPD and the next time you run the standalone script you will be awarded with the login prompt.

Now for my question. Where do i find xfsprogs for the kernel you are using.
I have tried several distro for armv5 but none seem to work. i desperately need the xfs_repair tool
as i do not have a system which can host 5 sata drives sadly to do xfs_repair via a live cd or whatever.

Thanks
wvwaard

[Jocko]

Hi wvwaard,

This is the area of competence of Fvdw but a few remarks:
- You must enable the DHCP server on your router.
- The console will only work if local IP are of type: 192.168.1.xx or 192.168.0.xx

So for a Telnet access, you must:
- Stop your NAS
- Run the tool fvdw-sl console
- Select Telnet : a help is displayed (read carefully here).

I do not think that the wanted binary is available with the standalone kernels. This will require to download it.
I think fvdw should be able to provide this binary. :tapfoot

[fvdw]

thanks for your feedback.
The standalone kernel needs static binaries otherwise it becomes too big. Therefor xfsprogs must be compiled static to work with this kernel. i will try to compile it for you otherwise there are other methods to get xfsprogs binaries running. Which specific binaries do you need from this package

[wvwaard]

Thanks for your fast replies,

i need the xfs_repair tool...

thanks
Wvwaard

[wvwaard]

Oke guys,

i have found a solution.
Build a system with 4 of the 5 drives installed
downloaded rescue live cd , booted via external dvd.
After reading a lot on xfs, i concluded that by using the mdadm --create
option the uuid changed on the array and therefore the log is seen as corrupted.
by running the following mount command i was able to access the file system
and i am now running a backup to an external hdd:

> # mount -oro,nouuid,norecovery /dev/md0 /mnt/backup

hope this helps others in restoring from this crap lacie system..

btw i bought two synology 2413 with mirroring ...which are great...

thanks
wvwaard :applause

[fvdw]

:thumbup glad to hear you got it solved , it save me some time to compile xfsprogs static, seems not so straight forward for that package. Anyhow no need for that.

About the 5big2, I think the box is not bad regarding hardware. A nice energy friendly ARM 1.2 GHz processor 512 MB RAM, 5 slots.
I run one myself but of course with the fvdw-sl firmware and have no problems.
Seems The Lacie firmware is the major contributer to the problems seen with the 5big2 which are by the way most of the time raid related. Maybe it is the stability of raid in general, I never liked it personally.
I use the 5big2 without raid and use a cron job to make an incremental backup once per day. I know I can loose some data if it fails in that day.

[wvwaard]

Thanks fvdw

i was using it on a windows 2003 storage server in our domain.
it was connected via the iscsi interface. Every once in a while the iscsi
was failing...i seems to me there is a memory / buffer issue im the kernel
as this was most of the time happening when copying a lot of files, i mean
more then a million...Propably lacie has never thought of using this machine
in middle mkb class companies and the trouble starts there. normaly a reset
of the system would bring back the iscsi connection with no further loss of data.
But not this time...sadly....i am not out of the mist yet it seems because not
all data can be read. because of the norecovery option you mount the system as is,
and in the case the log is still corrupted in some places...so still trying to avoid the
-L option on xfs_repair, copying everything i can and then as a last resort try the
damn -L option :-D

keep you posted, if all is done i will certainly install your firmware on it,
and you are right about the hardware, it is great, synology should work with lacie,
as the synology hardware is most of the time very flumsy

[fvdw]

wow you seem to be a real prof.I know using (remote) iscsi is a risk if you use it as r/w with multiple users, assuming you mean disks connected remotely via lan interface using for iscsi-target. As I understand you need to have locking file system like ntfs to prevent data corruption, which probably will be the filesystem you were using.
Our firmware currently use ext3 as format for the data partition so iscsi as shared folder is a no go unless you only use it for reading or single user. But why use iscsi remote, why not just samba ? I think performance in a windows environment is not much different.

Nice to hear that you consider to use our firmware, we hope you will like it, but remember we are just two people here making a hobby out of putting together open source code, and some of our own to make a nice package to control a NAS. So we should be no real match for all these Lacie and synology engineers ;)
ps In the efforts to develop our firmware we found however some questionable programming of the professionals :whistle They could do better..

[wvwaard]

Well fvdw,

never over estimate "pro" because we all are just humans trying to progress
in our own ways.... ;)

I wanted iscsi because of the tight intigration with the operating system.
For the storage server the disks would look like they where on the server its self...
i had thought about latency etc in the network maybe being a problem but as i said
it worked flawlessy...

still strugling with one directory that i cannot read.....sadly...

grtz
wvwaard