Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Sat May 26, 2018 6:42 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 67 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
 Post subject: Re: XFS fixed?
PostPosted: Sun Jan 04, 2009 5:45 pm 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
XFS either seems to work (as it does on my V1 box with every kernel I have) and not on others, like my other V1 and V2 boxes. I have spent some time on this and have had many mixed results. Just use JFS now on my other boxes.

_________________
LS used as PVR and streaming source


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 05, 2009 1:05 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
Oh my god, Buffalo is shipping XFS as the default fs for the data drives of the ARM boxes, how could ordinary customers handle such kind of corruption and shutdown when the fs is in use!?

It seems that heavy read / write operations with large numbers of small size files and directories will trigger the corruption and fs shutdown. I noticed that the same files.tar.gz if unpack within the Lunix environment using "tar -zxvf" seems to be okay but if unpack from the PC side using PC Utility into a "share" drive will have 90% chances to trigger the corruption and fs shutdown.

Do I need to compile a custom kernel in order to use JFS?

Below is the recovery logs:
Code:
- Reboot the system into EM Mode
# xfs_check /dev/ls_disk1_6
agf_freeblks 157109, counted 155834 in ag 12
bad nblocks 3 for free inode 336266079
agf_freeblks 1016215, counted 1010111 in ag 20
agi_count 2560, counted 2752 in ag 20
agi_freecount 2481, counted 2469 in ag 20
/usr/bin/xfs_check: line 62:   819 Killed     xfs_db$ISFILE -i -p xfs_check -c "check$OPTS" $1

# xfs_repair /dev/ls_disk1_6
Phase 1 - find and verify superblock...
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.
# # mount /dev/ls_disk1_6 /mnt/disk1
# umount /mnt/disk1

# xfs_repair /dev/ls_disk1_6
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - 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
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - agno = 32
        - agno = 33
        - agno = 34
        - agno = 35
        - agno = 36
        - agno = 37
        - agno = 38
        - agno = 39
        - agno = 40
        - agno = 41
        - agno = 42
        - agno = 43
        - agno = 44
        - agno = 45
        - agno = 46
        - agno = 47
        - agno = 48
        - agno = 49
        - agno = 50
        - agno = 51
        - agno = 52
        - agno = 53
        - agno = 54
        - agno = 55
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
entry "cirrus.dll" at block 3 offset 808 in directory inode 336016417 references free inode 336266079
        clearing inode number in entry at offset 808...
entry "cirrus.sys" at block 3 offset 832 in directory inode 336016417 references free inode 336266079
        clearing inode number in entry at offset 832...
entry "citohres.dll" at block 3 offset 856 in directory inode 336016417 references free inode 336266079
        clearing inode number in entry at offset 856...
entry "citohres.ini" at block 3 offset 880 in directory inode 336016417 references free inode 336266079
        clearing inode number in entry at offset 880...
entry "cl5465.dll" at block 3 offset 904 in directory inode 336016417 references free inode 336266079
        clearing inode number in entry at offset 904...
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - agno = 32
        - agno = 33
        - agno = 34
        - agno = 35
        - agno = 36
        - agno = 37
        - agno = 38
        - agno = 39
        - agno = 40
        - agno = 41
        - agno = 42
        - agno = 43
        - agno = 44
        - agno = 45
        - agno = 46
        - agno = 47
        - agno = 48
        - agno = 49
        - agno = 50
        - agno = 51
        - agno = 52
        - agno = 53
        - agno = 54
        - agno = 55
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
rebuilding directory inode 336016417
        - traversal finished ...
        - traversing all unattached subtrees ...
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
#

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 05, 2009 1:41 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
Sluk, it seem the ARM+XFS problems don't seem to manifest themselves any while one is using the Buffalo kernels (2.6.12.x and 2.6.16.x). I think it only became a problem in later kernels (can't remember what version it started w/ ...). It is still a problem in the current vanilla kernel, AFAIK.

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 05, 2009 4:07 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
@Davy
I am in Open Stock environment of the latest Japan version firmware and this official kernel is in 2.6.16... I can generate the problems at anytime I want... I don't think such kind of unstable fs can release for production use at all, shame on Buffalo's technical Dept. :down:

Quote:
root@HS-DHGL2B4:/proc# cat version
Linux version 2.6.16.16-arm1 (root@I.You) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #69 Wed Oct 1 10:59:37 JST 2008

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 05, 2009 4:23 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
hmmm... this is the first that I'd heard of such problems seen on the stockware/stock kernels. I don't use the stock firmware myself, just armel and foonas, and with a 2.6.27-ish kernel.

I agree, if data can be lost, it is a big problem. :shock:

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 05, 2009 4:31 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
How difficult for me to switch over to JFS... appreciated for advices and hints...

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 05, 2009 6:56 pm 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
JFS is a kernel rebuild. JFS is not part of the existing stock kernel. You could switch to ext2/3 if you wish as these do exist. My preference was JFS.

_________________
LS used as PVR and streaming source


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Mon Jan 12, 2009 6:33 pm 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
Now I have the JFS enabled GPL kernel...

I just converted /dev/sda2 rootfs to ext3 and /dev/sda6 to JFS but I found no means to get the boot process to mount the rootfs using ext3, modification on /etc/fstab doesn't works, dmesg shown the boot process still continue to attempt mounting /dev/sda2 with xfs. In fact, every xfs mount attempt will result in a corrupted sda2 and I have to mkfs.ext3 and restore everything... Beside, I think it seems not logical to specify mount option of sda2 in /etc/fstab because it is inside sda2! How can /etc/fstab be seen before sda2 being mounted? :oops:

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 10:25 am 
Offline
Regular Member

Joined: Mon Oct 15, 2007 5:21 am
Posts: 144
@sluk

Your problem with the boot process still trying to mount xfs is (I think) due to a change madeby buffalo in the
buffalo HSDHGL-1.20 (japan) firmware initrd.

If you go into initrd (mounted as / if you are in em mode) and look at the file linuxrc (which controls the
boot process, you will find the section

Quote:
fsck_disks()
{
##fsck_localdisks
echo "== fsck_dsks =="
fsck.ext3 -pyf /dev/${DEV_BOOT}
FsckXFS /dev/${DEV_ROOTFS1}
}

The call to FsckXFS is was not there in earlier firmware.

I think this call is likely to be your problem.
You will have to unpack initrd.img, change this, and repack (instructions are somewhere
in the wiki) if you want to use an ext3 rootfs with v 1.20 Buffalo firmware,
(or use an older initrd)


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 10:36 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
@duncan_h

Thanks for hunting this down.. I also found this as well by mounting the initrd.buffalo:

Code:
~/INITRD$ sudo grep DEV_ROOTFS1 linuxrc
   FsckXFS /dev/${DEV_ROOTFS1}
   mount -n -o rw /dev/${DEV_ROOTFS1} /mnt
      mount -n -o rw /dev/${DEV_ROOTFS1} /mnt

Apart from take out the FsckXFS call, I would expect "-t ext3" also need to be added to the above mount command to DEV_ROOTFS1 ?!

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 11:30 am 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
I produced a modified initrd image some time ago which works with stock and modified systems, plus adds standby with micro_evtd. This works with different formatted rootfs. Available in the downloads area.

_________________
LS used as PVR and streaming source


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 11:40 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
Thanks LB, I noticed that but how should fs for ext3 look like for your modified initrd?

Code:
## Advanced use only, specify system area format
 SYSTEM_FORMAT="mkfs.xfs -d agcount=4 -l size=32m"

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 12:24 pm 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
All you need to do is set OTHER_DISTRIBUTION=YES. The XFS option was added when XFS worked. You can ignore that. If you set SDA1 to ext2/3 it will get mounted correctly as it auto-detects the partition type.

[EDITED]

_________________
LS used as PVR and streaming source


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 1:23 pm 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
@LB

Just tried your initrd, no EXT3 mount attempt at all for sda2 ...
Quote:
sh-2.05b# dmesg | grep sda
Kernel command line: console=ttyS0,115200 root=/dev/sda2 rw initrd=0x00800040,15M panic=5 BOOTVER=1.10 tftpboot=yes
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 23 00 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 23 00 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda4 < sda5 sda6 sda7 sda8 >
sd 0:0:0:0: Attached scsi disk sda
EXT3 FS on sda1, internal journal
EXT3 FS on sda1, internal journal
EXT3 FS on sda1, internal journal
sh-2.05b#
sh-2.05b# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root.old 13303 12318 985 93% /
/dev/ram1 15360 2364 12996 15% /mnt/ram
/dev/ls_disk1_1 287785 14892 258035 5% /boot
sh-2.05b#
sh-2.05b# mkdir /mnt/rootfs
sh-2.05b# mount -t ext3 /dev/sda2 /mnt/rootfs
sh-2.05b# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root.old 13303 12319 984 93% /
/dev/ram1 15360 2364 12996 15% /mnt/ram
/dev/ls_disk1_1 287785 14892 258035 5% /boot
/dev/sda2 2893660 316136 2430532 12% /mnt/rootfs

Quote:
sh-2.05b# cat boot_options
## Correct MAC address
setMAC -s 00:16:XX:XX:XX:XX
## WOL port options in standby. Remove if WOL not required.
WOL=7
## Set to YES if not a stock box, comment out if stock box
OTHER_DISTRIBUTION=YES
## Define root path, comment out if stock box
ROOTPATH=/boot
## Advanced use only, specify system area format
SYSTEM_FORMAT="mkfs.xfs -d agcount=4 -l size=32m"
## Default is 509MB, set to size required and following update the disk
## will be re-sized. WARNING: Is destructive.
SDA2=909MB
## Set menu timeout (secs), default is 4. Disable, set to 0 or OFF. For
## EM mode set to EM
MENU_TIMEOUT=4
## Set to YES to delete hdd image following update or NO to leave it
REMOVE_HDDROOTFS=NO
## Reset watchdog & fan as micocontroller does not do this after reboot
micro_evtd -q -s 013501,013300


Also,INFO light flashing...

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
 Post subject: Re: XFS fixed?
PostPosted: Tue Jan 13, 2009 1:35 pm 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
@duncan_h
duncan_h wrote:
You will have to unpack initrd.img, change this, and repack ...

Changed linuxrc as follow:
Code:
fsck_disks()
{
   ##fsck_localdisks
   echo "== fsck_disks =="
   ##FsckXFS disabled just provide "Done." output
   FsckXFS /dev/${DEV_ROOTFS1}
   fsck.ext3 -pyf /dev/${DEV_BOOT}
   fsck.ext3 -pyf /dev/${DEV_ROOTFS1}
}

and usr/local/bin libbuffalo:
Code:
FsckXFS()
{
   logger -t FsckXFS -p local0.info "try to repair XFS...."
   ## Mount the filesystem to replay the log, and unmount it before
   ## re-running xfs_repair. 
   ##TMP=`dd if=$1 bs=1 count=4`
   ##if [ "$TMP" = "XFSB" ]; then
   ##   mkdir -p /var/tmp/fsckpoint
   ##   mount -t xfs $1 /var/tmp/fsckpoint
   ##   umount /var/tmp/fsckpoint
   ##   xfs_repair $1
      logger -t FsckXFS -p local0.info "done."
   ##else
   ##   logger -t FsckXFS -p local0.info "$TMP. giveup."
   ##fi
}


Still doesn't works... but I do found EXT3 mounting messages in dmesg for sda2, but cannot see it being mount to / and the box ended up in EM-Mode. However, no more corruption on sda2.

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 67 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited