Re: FFS corruption
I wrote "that's an inode"; now in living colour: On Mon, Nov 20, 2017 at 08:09:28AM +, Emmanuel Dreyfus wrote: > 80 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 di_mode = 0x8180 = 0100600 (mode 600 regular file) di_nlink = 1 di_oldids = 0 (uninteresting) di_size = 0 > 0010 5a 8d 0e 5a 60 8e 09 0f 5a 8d 0e 5a 60 8e 09 0f > 0020 5a 8d 0e 5a 60 8e 09 0f 00 00 00 00 00 00 00 00 di_atime = di_mtime = di_ctime = 1510903130.252284512 = Fri Nov 17 07:18:50.252284512 UTC 2017 > 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * > 0060 00 00 00 00 00 00 00 00 00 00 00 00 f4 4e a9 72 di_db[] = di_ib[] = all zero (consistent with size of 0) di_flags = 0 di_blocks = 0 di_gen = 1923698420 > 0070 90 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 di_uid = 400 di_gid = 0 di_modrev = 0 > 0080 80 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0090 7f 8d 0e 5a 7e 77 dc 25 7f 8d 0e 5a 7e 77 dc 25 > 00a0 7f 8d 0e 5a 7e 77 dc 25 00 00 00 00 00 00 00 00 > 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * > 00e0 00 00 00 00 00 00 00 00 00 00 00 00 8b 73 ed 77 > 00f0 90 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Next inode: pretty much the same except the time is Fri Nov 17 07:19:27 UTC 2017, and the generation number is different (which is expected...) > 0100 80 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0110 92 8d 0e 5a 54 43 af 15 92 8d 0e 5a 54 43 af 15 > 0120 92 8d 0e 5a 54 43 af 15 00 00 00 00 00 00 00 00 > 0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * and this one's a few seconds later. Unfortunately ffs inodes don't contain their own identity, but if you run out of other ideas you can probably search for a file with generation number 1923698420, and then if the file with the next inode number after it (likely, but not necessarily, in the same directory) has generation number 2012050315 you've found where it's coming from. Of course these might have gone away and been replaced in the meantime depending... -- David A. Holland dholl...@netbsd.org
Re: FFS corruption
On Mon, Nov 20, 2017 at 03:38:32PM -0500, Mouse wrote: > dholland's identification of the overwrite data as inodes certainly > does feel provocative, but I'm not sure what to make of it. Inodes and data blocks should appear in strictly disjoint regions of the fs image. Therefore, either something is *very* badly borked or your theory about overlapping images is the best explanation. Another possibility is that the dom0 fs is corrupt. Has *it* been fscked? -- David A. Holland dholl...@netbsd.org
Re: increase softint_bytes
On 2017/11/21 17:03, matthew green wrote:
It'll take a little time to write this change. And, it's low level
and important code, so it will take a time to test the stability
before sending pullup request. So,
0) Apply the following change to -current.
Index: kern_softint.c
===
RCS file: /cvsroot/src/sys/kern/kern_softint.c,v
retrieving revision 1.43
diff -u -p -r1.43 kern_softint.c
--- kern_softint.c 4 Jul 2016 04:20:14 - 1.43
+++ kern_softint.c 21 Nov 2017 06:41:35 -
@@ -217,7 +217,7 @@ typedef struct softcpu {
static void softint_thread(void *);
-u_int softint_bytes = 8192;
+u_int softint_bytes = 16384;
u_intsoftint_timing;
static u_int softint_max;
static kmutex_t softint_lock;
1) Sent the pullup request to netbsd-8
2) Write auto-resize code and commit.
3) If it's stable, send the pullup request to netbsd-8.
sounds good to me. i would even be ok with a switch
to 16k or even 32k (platform basis?)) for netbsd-8 or
Committed with 32K.
Thanks!
earlier right now and allow the resize code to live in
-current until -9.
thanks!
.mrg.
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
re: increase softint_bytes
> It'll take a little time to write this change. And, it's low level
> and important code, so it will take a time to test the stability
> before sending pullup request. So,
>
> 0) Apply the following change to -current.
>
>
> Index: kern_softint.c
> ===
> RCS file: /cvsroot/src/sys/kern/kern_softint.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 kern_softint.c
> --- kern_softint.c4 Jul 2016 04:20:14 - 1.43
> +++ kern_softint.c21 Nov 2017 06:41:35 -
> @@ -217,7 +217,7 @@ typedef struct softcpu {
>
> static void softint_thread(void *);
>
> -u_intsoftint_bytes = 8192;
> +u_intsoftint_bytes = 16384;
> u_int softint_timing;
> static u_intsoftint_max;
> static kmutex_t softint_lock;
>
>
> 1) Sent the pullup request to netbsd-8
>
> 2) Write auto-resize code and commit.
>
> 3) If it's stable, send the pullup request to netbsd-8.
sounds good to me. i would even be ok with a switch
to 16k or even 32k (platform basis?)) for netbsd-8 or
earlier right now and allow the resize code to live in
-current until -9.
thanks!
.mrg.
