Chris Pascoe wrote:
>
> > I get a repeatable crash immediately on 017 with these changes. Same
> > machine as before (1GB/Dual P3-Xeon), just a slightly different partiton
> > layout. Was I supposed to avoid test 017 too?
>
> Avoiding tests 013, 017, 049 (and all the tape ones!), the stress tests
> have completed 3 passes now.. Hmm, must have seen me typing - 042 just
> failed (running SMP/highmem again).
My SMP worked on 042 without fail; this was from the 2.4.6-pre1, are you
using this version too?
I did have 049 fail, "!!! failed to loop mount xfs", as well as 053
giving a lot of fails due to unimplemented functions. I am still
wondering about the post I gave for my failed tests, but I can add
something of an experiment I did. For the use of encrypted filesystem
partitions, it requires use of loop device. Should something happen to
the encrypted system, such as power fail or power off, one has to do any
sort of filesystem recovery through the loop device. That in turn
requires mounting the partition and then running the test against
/dev/loop0 (or maybe loop1 if it was the second encrypted system to
mount). But xfs_repair refuses to run on a mounted system. So I might
suggest that xfs_repair be allowed on a mounted system, provided some
circumstances are met. One, which I am not sure if is possible, is that
it could be allowed to run if it is detected to be a loopback device; if
this detection isn't possible, there might be a need for a flag to allow
forced repair (maybe the encrypted partition could be mounted read
only?).
Anyway, the other limitation is that during the creation of a loopback
encrypted partition, the mkfs.xfs causes an error note about block size
parameter not being valid. This didn't seem to make any big impact,
because I was able to create an XOR loopback layer over a partition, and
still run mkfs.xfs. I then copied a large amount of data over, and
intentionally shut the power off without unmounting it (it wasn't
writing at the time though). When I brought it back up, mounting it with
the encryption password worked fine, and under superficial inspection it
appeared to be ok. I did not check it close enough to know if it really
was ok, so it might not be as good as it seems.
If anyone is interested in seeing what happens, you can create an
encrypted partition via something like this (I'll assume /dev/hda4;
normally you would also pad the partition with random bytes first, I
won't for this):
losetup -e XOR /dev/loop0 /dev/hda4
[enter some easy to remember pass]
mkfs.xfs /dev/loop0
losetup -d /dev/loop0
Now to mount it:
mount /dev/hda4 /mnt/somewhere -t xfs -oloop,encryption=xor
[enter pass]
You should be able to use the partition normally at /mnt/somewhere. Now
if you wanted to run repair on it and it was ext2, you'd mount it this
way and run:
fsck.ext2 /dev/loop0
Running instead
fsck.xfs /dev/loop0
will run and not say anything...does this mean it didn't do anything? Or
just that it was clean?
If instead I wanted to run xfs_repair, it will refuse...I suppose it may
not be appropriate even, should xfs_repair be useful against loopback
devices?
D. Stimits, stimits@xxxxxxxxxx
>
> Active process was:
> 0xef9e6000 00005670 00005669 1 001 run 0xef9e6350*xfs_fsr
>
> 042 90s ...Start mounting filesystem: sd(8,19)
> Ending clean XFS mount for filesystem: sd(8,19)
> Start mounting filesystem: sd(8,19)
> Ending clean XFS mount for filesystem: sd(8,19)
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> printing eip:
> c0161ea4
> *pde = 00000000
>
> Entering kdb (current=0xef9e6000, pid 5670) on processor 1 Oops: Oops
> due to oops @ 0xc0161ea4
> eax = 0x00000000 ebx = 0xc4b09d60 ecx = 0x00000009 edx = 0x00000000
> esi = 0x4014e200 edi = 0x00000000 esp = 0xef9e7d7c eip = 0xc0161ea4
> ebp = 0xef9e7db8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246
> xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xef9e7d48
> [1]kdb> bt
> EBP EIP Function(args)
> 0xef9e7db8 0xc0161ea4 _pb_direct_io+0x90 (0xf3594240, 0x0, 0x0, 0x100000,
> 0xef9e7e1c)
> kernel .text 0xc0100000 0xc0161e14 0xc0161fd4
> 0xef9e7e3c 0xc0163285 _pagebuf_file_write+0x175 (0xd8a99320, 0x4014e200,
> 0x100000, 0xef9e7ea8,
0xc01cea90)
> kernel .text 0xc0100000 0xc0163110 0xc016330c
> 0xef9e7eb0 0xc016340d pagebuf_generic_file_write+0x101 (0xd8a99320,
> 0x4014e200, 0x100000,
0xef9e7f84, 0xc01cea90)
> kernel .text 0xc0100000 0xc016330c 0xc016374c
> 0xef9e7f34 0xc01cfd98 xfs_write+0x348 (0xece267a8, 0xef9e7f78, 0x0, 0x0, 0x0)
> kernel .text 0xc0100000 0xc01cfa50 0xc01d0054
> 0xef9e7f98 0xc01cb765 linvfs_write+0x10d (0xd8a99320, 0x4014e200, 0x100000,
> 0xd8a99340)
> kernel .text 0xc0100000 0xc01cb658 0xc01cb7a0
> 0xef9e7fbc 0xc0136175 sys_write+0x95 (0x7, 0x4014e200, 0x100000, 0x100000,
> 0x100000)
> kernel .text 0xc0100000 0xc01360e0 0xc01361b0
> 0xc0106fcb system_call+0x33
> kernel .text 0xc0100000 0xc0106f98 0xc0106fd0
>
> Chris
|