Date: Wed, 1 Oct 2014 17:12:19 +0000 From: "Pokala, Ravi" <rpokala@panasas.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: dumpsys/savecore on AF-4Kn drives? Message-ID: <D0518336.121BA9%rpokala@panasas.com> In-Reply-To: <D050827F.121A5C%rpokala@panasas.com> References: <D050827F.121A5C%rpokala@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Re-posting something that was sent to me off-list, so the thread stays up-to-date: From: <Meyer>, Conrad <conrad.meyer@isilon.com> Date: Wednesday, October 1, 2014 at 6:05 AM To: Ravi Pokala <rpokala@panasas.com> Subject: RE: dumpsys/savecore on AF-4Kn drives? Ravi, Skipping freebsd-hackers@ as I can't get Outlook to reply in the right way. savecore(1) uses raw read(2) calls to the passed device. FreeBSD DevFS doesn't support non-native block sizes, so that's probably where EINVAL is coming from. To support 4Kn from that end you could probably convert savecore(1) from read(2) and friends to fread(3) (assuming libc does the right thing re: native sector size). The kernel dump code is all DEV_BSIZE (512), but the backing dump device is free to do Read-Modify-Write to satisfy those 512 byte writes during dump. I don't know if gmirror does this, but if you were able to create a dump without error/panic, it probably does. Most of this code hasn't been touched since 2002 or so, 4Kn is a project :). Good luck! Hope that helps, Conrad -----Original Message----- From: <Pokala>, Ravi Pokala <rpokala@panasas.com> Date: Tuesday, September 30, 2014 at 3:53 PM To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: dumpsys/savecore on AF-4Kn drives? >Hi folks, > >Does anyone out there have AF-4Kn drives (both logical and physical sector >size is 4KB)? Have you been able to drop a core to one, and successfully >save the core on the way back up? > >I'm working on adding AF-4Kn support to an older version of FreeBSD (based >on 7 - yeah, I know... :-P), using -CURRENT as a reference. Things look >good at the GEOM level and higher; the GEOM utils report correct sizes, >UFS runs fine, etc. If I manually break into the debugger and 'call >doadump', it appears to work; at least, it does not report any errors. But >when I reboot, `savecore' complains: > > error reading dump header at offset 0 in /dev/mirror/gm1: Invalid >argument > >(Yes, it's dumping to a mirror; no, that's not the problem: the mirror is >configured using the 'prefer' balancing algorithm, as described in >gmirror(8), and we've been doing this without issue for years.) > >I'm trying to figure out if the problem is on the dumpsys side, the >savecore side, or if they're both broken for AF-4Kn. In particular, >'struct kerneldumpheader' is 512 bytes, and it looks like most calls to >dump_write() in the full-dump context (not minidumps) pass either the size >of the structure, or an explicit 512, for the 'length' argument. That's >the case in both the 7-ish version I'm porting to, and in -CURRENT. > >There's no AF-4Kn-aware bootstrap in the version we're using (emaste@ - >does the new UEFI bootstrap in 10-STABLE work w/ AF-4Kn drives?), so one >of the drives is 512n, and I could probably find some space on there to >save the core to. But that device is small, and we have other uses for it, >so I'd like to avoid reserving a large chunk of it. > >Any thoughts? > >Thanks, > >Ravi >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0518336.121BA9%rpokala>