Pavel Machek wrote:
>
>Maybe the card is pretty close to going to crash, but... two disk
>successive disk errors still should not be cause for journal
>corruption.
>
>[Also errors could be corelated. Imagine severe overheat. You'll
>successive failing writes, but if you let cool it down, you'll
Hi!
> >>* Transport problem. The driver will report back a CRC error, timeout or
> >>whatnot and break. We might not know how many sectors survived so we try
> >>again, going sector-by-sector. We might get a transfer error again,
> >>possibly even before the previous one. But at this point the
Hi!
* Transport problem. The driver will report back a CRC error, timeout or
whatnot and break. We might not know how many sectors survived so we try
again, going sector-by-sector. We might get a transfer error again,
possibly even before the previous one. But at this point the transport
is
Pavel Machek wrote:
Maybe the card is pretty close to going to crash, but... two disk
successive disk errors still should not be cause for journal
corruption.
[Also errors could be corelated. Imagine severe overheat. You'll
successive failing writes, but if you let cool it down, you'll still
Pavel Machek wrote:
>>* Transport problem. The driver will report back a CRC error, timeout or
>>whatnot and break. We might not know how many sectors survived so we try
>>again, going sector-by-sector. We might get a transfer error again,
>>possibly even before the previous one. But at this
Hi!
> >>We had this discussion on LKML and Alan Cox' comment on it was that a
> >>solution like this would be acceptable, where we try and shove
> >>everything out first and then fall back on sector-by-sector to determine
> >>where an error occurs. This will only break if the problematic sector
>
Alan Cox wrote:
>On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
>
>
>>everything out first and then fall back on sector-by-sector to determine
>>where an error occurs. This will only break if the problematic sector
>>keeps shifting around, but at that point the card is probably toast
On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
> everything out first and then fall back on sector-by-sector to determine
> where an error occurs. This will only break if the problematic sector
> keeps shifting around, but at that point the card is probably toast
> anyway (if the thing
Russell King wrote:
>On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
>
>
>>We had this discussion on LKML and Alan Cox' comment on it was that a
>>solution like this would be acceptable, where we try and shove
>>everything out first and then fall back on sector-by-sector to
On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
> We had this discussion on LKML and Alan Cox' comment on it was that a
> solution like this would be acceptable, where we try and shove
> everything out first and then fall back on sector-by-sector to determine
> where an error
Russell King wrote:
>
>I'd rather not. The problem is that we have a host (thanks Intel)
>which is unable to report how many bytes were transferred before an
>error occurs. My fear is that doing anything other than sector by
>sector write will lead to corruption should an error occur.
>
On Wed, Aug 17, 2005 at 10:48:05PM -0700, Andrew Morton wrote:
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
> >
> > >I'm thinking that it would be better to not have the config option there
> > >and then re-add it late in the 2.6.14 cycle if someone reports problems
> > >which cannot be fixed. Or
On Wed, Aug 17, 2005 at 10:48:05PM -0700, Andrew Morton wrote:
Pierre Ossman [EMAIL PROTECTED] wrote:
I'm thinking that it would be better to not have the config option there
and then re-add it late in the 2.6.14 cycle if someone reports problems
which cannot be fixed. Or at least make
Russell King wrote:
I'd rather not. The problem is that we have a host (thanks Intel)
which is unable to report how many bytes were transferred before an
error occurs. My fear is that doing anything other than sector by
sector write will lead to corruption should an error occur.
However, I've
On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
We had this discussion on LKML and Alan Cox' comment on it was that a
solution like this would be acceptable, where we try and shove
everything out first and then fall back on sector-by-sector to determine
where an error occurs.
Russell King wrote:
On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
We had this discussion on LKML and Alan Cox' comment on it was that a
solution like this would be acceptable, where we try and shove
everything out first and then fall back on sector-by-sector to determine
On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
everything out first and then fall back on sector-by-sector to determine
where an error occurs. This will only break if the problematic sector
keeps shifting around, but at that point the card is probably toast
anyway (if the thing keeps
Alan Cox wrote:
On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
everything out first and then fall back on sector-by-sector to determine
where an error occurs. This will only break if the problematic sector
keeps shifting around, but at that point the card is probably toast
anyway (if
Hi!
We had this discussion on LKML and Alan Cox' comment on it was that a
solution like this would be acceptable, where we try and shove
everything out first and then fall back on sector-by-sector to determine
where an error occurs. This will only break if the problematic sector
keeps
Pavel Machek wrote:
* Transport problem. The driver will report back a CRC error, timeout or
whatnot and break. We might not know how many sectors survived so we try
again, going sector-by-sector. We might get a transfer error again,
possibly even before the previous one. But at this point the
Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> >I'm thinking that it would be better to not have the config option there
> >and then re-add it late in the 2.6.14 cycle if someone reports problems
> >which cannot be fixed. Or at least make it default to 'y' so we get more
> >testing coverage,
Andrew Morton wrote:
>The fact that this is enabled under the experimental
>CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK
>then we should just enable it unconditionally, no?
>
>
>
It was made this way to make Russell more open to it. I have since not
recieved any
Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> Adds support for writing multiple sectors at once. This allows
> back-to-back transfers of sectors giving roughly double write throughput.
>
> To be able to detect which sector is causing problems the system falls
> back to single sector writes if a
Pierre Ossman [EMAIL PROTECTED] wrote:
Adds support for writing multiple sectors at once. This allows
back-to-back transfers of sectors giving roughly double write throughput.
To be able to detect which sector is causing problems the system falls
back to single sector writes if a failure is
Andrew Morton wrote:
The fact that this is enabled under the experimental
CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK
then we should just enable it unconditionally, no?
It was made this way to make Russell more open to it. I have since not
recieved any more
Pierre Ossman [EMAIL PROTECTED] wrote:
I'm thinking that it would be better to not have the config option there
and then re-add it late in the 2.6.14 cycle if someone reports problems
which cannot be fixed. Or at least make it default to 'y' so we get more
testing coverage, then remove
Adds support for writing multiple sectors at once. This allows
back-to-back transfers of sectors giving roughly double write throughput.
To be able to detect which sector is causing problems the system falls
back to single sector writes if a failure is detected.
Tested by several people with no
Adds support for writing multiple sectors at once. This allows
back-to-back transfers of sectors giving roughly double write throughput.
To be able to detect which sector is causing problems the system falls
back to single sector writes if a failure is detected.
Tested by several people with no
28 matches
Mail list logo
