On Sat, 2008-01-19 at 07:58 +0900, Tejun Heo wrote:
Matt Mackall wrote:
On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote:
And mprintk the following.
code:
DEFINE_MPRINTK(mp, 2 * 80);
mprintk_set_header(mp, KERN_INFO ata%u.%2u: , 1, 0);
mprintk_push(mp, ATA %d, 7
On Tue, 2008-01-22 at 10:00 +0900, Tejun Heo wrote:
Matt Mackall wrote:
I suppose. I still find this approach less than ideal, especially
putting something potentially large on the stack. The dangers are
perhaps worse than a malloc, really.
I pondered on this a bit but the thing is we
On Fri, 2008-01-18 at 11:44 -0700, Matthew Wilcox wrote:
On Fri, Jan 18, 2008 at 12:41:08PM -0600, Matt Mackall wrote:
On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote:
And mprintk the following.
code:
DEFINE_MPRINTK(mp, 2 * 80);
mprintk_set_header(mp, KERN_INFO ata
On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote:
And mprintk the following.
code:
DEFINE_MPRINTK(mp, 2 * 80);
mprintk_set_header(mp, KERN_INFO ata%u.%2u: , 1, 0);
mprintk_push(mp, ATA %d, 7);
mprintk_push(mp, , %u sectors\n, 1024);
mprintk(mp, everything seems dandy\n);
On Fri, Feb 02, 2007 at 11:06:19AM -0500, Mark Lord wrote:
Alan wrote:
If this is the right strategy for disk recovery for a given type of
device then this ought to be an automatic strategy. Most end users will
not have the knowledge to frob about in sysfs, and if the bad sector hits
at the
On Fri, Feb 02, 2007 at 05:58:04PM -0500, Mark Lord wrote:
Matt Mackall wrote:
..
Also worth considering is that spending minutes trying to reread
damaged sectors is likely to accelerate your death spiral. More data
may be recoverable if you give up quickly in a first pass, then go
back
