bsuparna@xxxxxxxxxx wrote:
>
> >True, it is more difficult, but look at it from another perspective.
> >Most of the I/O code involves either the disk driver itself, or some
> >intermediary layer. I'd like to throw out most of the request code
> >and buffer code in the I/O path, and stick to just writing pages of
> >memory (specific ones at that) to the device.
> >
> >So you'd have a:
> >
> > dump_write()
> > dump_io_write()
> > dump_scsi_write() or dump_ide_write()
> >
> >The last one is simply a frame pointer depending on the dump device
> >that is configured. And you still use the standard I/O path for
> >checking the partition, making sure it's a valid device, getting
> >device information and status, etc., when you call dump_open().
> >That way when the crash occurs, all you have to do is use stored
> >data from the current dump device tables (sizes, etc.), and just
> >write out the pages of memory in some block size format.
> >
> >The dump I/O driver does only ONE thing; it writes. It doesn't
> >need to read, open, close, or any of that. Everything else is
> >cached early on during the boot-up process when dump_open() is
> >called.
> >
> >Does that sound legitimate?
>
> We'll need to study some of the low level i/o driver code to see if there
> is any way to achieve something like this in a generic way for all scsi
> adapters, say (is that what you intended ?) ... but this may be a little
> more complicated than it appears at the outset, considering more involved
> or specialized driver logic for certain configurations and adapter
> characteristics.
That's fine ... but IMHO, you build the driver function DIRECTLY into
the driver in question. I wish they used a file_ops-like mechanism where
you could determine the driver functions available and use those, if
they exist, that way if a driver doesn't have a scsi_dump() operations
tag, it doesn't support dumping.
> There may also be a few additional things to think of (beyond the initial
> dump_open). For example there may be a need to suspend/clear other i/o or
> reset the dump device if the h/w was in use by the running system, before
> dump can start. There would have to be some way to determine when a write
> has completed (typically poll mode or in some way that avoids using the
> system's interrupt handling code) so that the next write request can be
> sent. All of this code shouldn't share any state with the standard driver.
Agreed.
> AIX has a dump interface architected for device drivers, a little like what
> you suggest, but we weren't sure how feasible it would be to provide
> something of that sort on linux, considering the range of hardware and
> third party drivers to consider. Did you have some feedback from driver
> maintainers about this ? I remember you had once mentioned that Linus had
> suggested the need for a raw dump i/o interface during earlier discussions
> about incorporating lkcd into the kernel.
Feedback from driver maintainers? :) I think it has to be done on a one-by-one
basis. I realize it may be difficult, but even if we end up sending out
patches to their drivers, it's the right solution in the long run. If
driver_ops were being used, each driver writer (for new devices) would
try to fill in that driver requirement before inclusion in the kernel.
That would ultimately be the goal ...
Since you're going down, there are a lot of things about what's in the
buffer cache that you don't worry about (for disruptive dumps). In
addition, you throw out the request queue, because in theory, nothing
for the device and partition you're targetting should be on that queue.
The biggest thing you worry about is interrupt state. Solve that, and
most of the other problems go away.
> I'll be away at OLS and on vacation for a week after that, so will continue
> these discussions then.
> Bharata will be around, though.
>
> Regards
> Suparna
Sounds good. Enjoy OLS -- sorry I can't make it. :)
--Matt
>
> Suparna Bhattacharya
> IBM Software Lab, India
> E-mail : bsuparna@xxxxxxxxxx
> Phone : 91-80-5267117, Extn : 2525
|