reiserfs on software raid on sparc/2.4.18 ?
not pretty!
is it possible ?
sparky:/usr/share/doc/raidtools2/examples# mkreiserfs /dev/md0
<-------------mkreiserfs, 2002------------->
reiserfsprogs 3.x.1b
mkreiserfs: Guessing about desired format..
mkreiserfs: Kernel 2.4.18 is running.
Format 3.6 with standard journal
Count of blocks on the device: 261856
Number of blocks consumed by mkreiserfs formatting process: 8219
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: 31588a0a-6b68-4db8-a873-a2e977ec97a1
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/md0'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
data_access_exception: SFSR[0000000000801009] SFAR[fffff802316856fc], going.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
mkreiserfs(215): Dax
TSTATE: 0000000011009604 TPC: 0000000000588a84 TNPC: 0000000000588a88 Y:
00000001 Not tainted
g0: fffff800099dc6e8 g1: fffee0022217c700 g2: 0000000000000001 g3:
fffee0022217c6dc
g4: fffff80000000000 g5: fffee0022217c720 g6: fffff8000ecf0000 g7:
0000000000000054
o0: 00000000001ff6f0 o1: 0000000000000000 o2: fffff8000f2b53c0 o3:
000000000044e000
o4: 0000000000000002 o5: 0000000000000000 sp: fffff8000ecf2ea1 ret_pc:
fffff8000f50901c
l0: fffff8000f509000 l1: fffff8000f509448 l2: 0000000000659000 l3:
0000000000000002
l4: 0000000000000000 l5: 0000000000000004 l6: 0000000000000000 l7:
0000000000000008
i0: fffed802316856fc i1: 0000000000000000 i2: 0000000000000000 i3:
0000000000000001
i4: 0000000000000000 i5: fffff8000f509000 i6: fffff8000ecf2f61 i7:
0000000000588ce0
Caller[0000000000588ce0]
Caller[000000000058afc0]
Caller[0000000000534d70]
Caller[0000000000534e60]
Caller[000000000045f2c4]
Caller[0000000000462b6c]
Caller[000000000044dc90]
Caller[000000000044e0cc]
Caller[000000000045bdf0]
Caller[0000000000410674]
Caller[00000000000135b8]
Instruction DUMP: 80a6c01c 02400038 8600ffdc <c4060000> 80a0a000
124ffff3 80a6e000 c400c00f 80a0a000
TSTATE: 0000000011009604 TPC: 0000000000588a84 TNPC: 0000000000588a88 Y:
00000001 Not tainted
g0: fffff800099dc6e8 g1: fffee0022217c700 g2: 0000000000000001 g3:
fffee0022217c6dc
g4: fffff80000000000 g5: fffee0022217c720 g6: fffff8000ecf0000 g7:
0000000000000054
o0: 00000000001ff6f0 o1: 0000000000000000 o2: fffff8000f2b53c0 o3:
000000000044e000
o4: 0000000000000002 o5: 0000000000000000 sp: fffff8000ecf2ea1 ret_pc:
fffff8000f50901c
l0: fffff8000f509000 l1: fffff8000f509448 l2: 0000000000659000 l3:
0000000000000002
l4: 0000000000000000 l5: 0000000000000004 l6: 0000000000000000 l7:
0000000000000008
i0: fffed802316856fc i1: 0000000000000000 i2: 0000000000000000 i3:
0000000000000001
i4: 0000000000000000 i5: fffff8000f509000 i6: fffff8000ecf2f61 i7:
0000000000588ce0
Caller[0000000000588ce0]
Caller[000000000058afc0]
Caller[0000000000534d70]
Caller[0000000000534e60]
Caller[000000000045f2c4]
Caller[0000000000462b6c]
Caller[000000000044dc90]
Caller[000000000044e0cc]
Caller[000000000045bdf0]
Caller[0000000000410674]
Caller[00000000000135b8]
Instruction DUMP: 80a6c01c 02400038 8600ffdc <c4060000> 80a0a000
124ffff3 80a6e000 c400c00f 80a0a000
Killed
(running a custom kernel built from debian's 2.4.18 tree)
nate
Reply to: