RE: Blockbusting news, results end

RE: Blockbusting news, results end

[Mudama, Eric]

>-----Original Message-----
>> If a drive wants to reallocate a block, but due to some temporary
>> condition is unable to (vibration, excessive temperature, 
>> etc), odds are there's no way for that drive to "remember" that
>> it needs to reassign that block, so if you reboot the drive or
>> reset it or whatever, you're back at square 1.
> 
> Bingo.  This is why reallocation at the time of a failed read is also
> necessary.  Yes the data are lost, yes the failure needs to 
> be both logged (once) and displayed to the user (once), yes if an 
> application reads it again before writing then it will be garbage
> or zeroes, but get the LBA sector number moved to a place that is
> less likely to be unreliable.
> 
> Meanwhile software must still make up for defective firmware.
> 

Reallocating on a failed read doesn't always make sense.  Some huge
percentage of the errors on the media are caused by poor writes due to
various transient conditions (temperature, shock events, etc), and are not
actual media defects that prevent writing there in the future.  If we get an
ECC error, the only thing we can "reallocate" is the stuff with the error in
it, in which case you're no closer to getting a good block of data than you
were prior to the reallocation.

If you try to write to that LBA, it should detect that you're writing to a
marginal area, and do some amount of tests to make sure that the new write
can be read.

Also, your term "defective firmware" is getting annoying.  What, exactly,
should a drive that knows it cannot access the media due to severe
environmental conditions do in firmware to remember its problems between
power cycles?

--eric

RE: Blockbusting news, results end

[Mudama, Eric]

> -----Original Message-----
> From: Norman Diamond
> 
> Someone else in this discussion estimated that physical 
> sectors are around 1MB these days.  My friends at Toshiba
> confirmed that physical sectors are much larger than
> logical sectors.  The physical sector size resembles that
> 1MB estimate far better than the 512B logical sector size.

I don't think your friends know what they're talking about.

Disk drives that use anything resembling the "standard" channel technology
have 2 physical sector types: servo sectors and data sectors.  Servo sectors
are designed to give the servo system a constant sample rate at any radius,
therefore they're constant in time, but get physically closer as you get
closer to the ID of the drive.  Data sectors are a fixed size, to hold a
certain number of user bytes of data, and they can be split, etc, as needed
to fit them nicely on the drive.

A modern disk has "a few" data sectors per servo sector at the OD (think
3-4.5), and "a few less" at the ID of the drive. (think 1.5-2).

The 1MB number can't possibly be a servo sector, since a modern drive
transfers ~50-70MB/sec, which would imply that their servo system is holding
postion within microns, only sampling 50-70 times/second.

I don't think any modern drive can hold 1MB on a single track, I know what
our current limit is, and we're not there yet.  (Anyone can figure this out
by looking at sequential read throughput per revolution)

That would mean that to be 1MB for a data sector, or anywhere close, they're
spanning a single data cylinder across tracks.  This doesn't make sense
either.

What I think is possible, but still unlikely, is that their defect
management scheme might not be capable of handling single-block defects.
However, disk drives have had that ability for tens of years, I can't see
how they could possibly sell a drive that way.

There's also a chance that in doing the larger write, you "cleaned up" a
poorly written adjacent track or ratty servo burst, which could account for
it working now.

Other than the track size and the DRAM buffer size, I can't think of
anything else offhand in a disk drive that is "about 1MB"

The insides of these things are near voodoo-magic...

> It is really hard to imagine a physical sector still being 
> 512B because the inter-sector gaps would take some huge
> multiple of the space occupied by the sectors.

We measure these gaps in nanoseconds.  They're not that huge.  But yes,
moving to a larger standard sector size would get you a significantly larger
disk drive built from the same parts.

> I'm sure the physical sectors are not 512B.

I'm sure you're wrong.

I'd imagine that since Seagate and WD and Maxtor are constantly duking it
out to release the next generation of capacity, and we all wind up producing
nearly-identical products when all is said and done, that they're using 512B
data sectors also.

Re: Blockbusting news, results end

[bill davidsen]

In article <785F348679A4D5119A0C009027DE33C105CDB3CA@mcoexc04.mlm.maxtor.com>,
Mudama, Eric <eric_mudama@Maxtor.com> wrote:
| 
| 
| > -----Original Message-----
| > From: Norman Diamond

| > It is really hard to imagine a physical sector still being 
| > 512B because the inter-sector gaps would take some huge
| > multiple of the space occupied by the sectors.
| 
| We measure these gaps in nanoseconds.  They're not that huge.  But yes,
| moving to a larger standard sector size would get you a significantly larger
| disk drive built from the same parts.

Given that we did that back in the CP/M days (late 70's) on floppy, and
with MFM, RLL and finally SCSI drives in the 70's, I would hope that
current drives use large sectors since the drive now has local cache
and doesn't need a fancy driver to do the caching!

| > I'm sure the physical sectors are not 512B.
| 
| I'm sure you're wrong.
| 
| I'd imagine that since Seagate and WD and Maxtor are constantly duking it
| out to release the next generation of capacity, and we all wind up producing
| nearly-identical products when all is said and done, that they're using 512B
| data sectors also.

Given that the IRG is fixed size regardless of sector size, I certainly
hope I misread what you say or you are incorrect. The difference
between 512B and 4KB sectors should be about 20-40% added capacity per
track (seven IRG sizes). I would expect large sectors would be
standard.

We used to diddle interleave when formatting as well, until we put full
track caching in the device driver.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Blockbusting news, results end

[Norman Diamond]

jw schultz wrote:

> > I am assuming that these numbers are applicable (one is
> > unknown):
> > logical sector size == 512B
> > physical sector size == ???B
> > page size/filesystem block size == 4KB
>
> I have dialoged with Eric Mudama.  He is 99% sure that no
> manufacturer of is making ATA drives with physical sectors
> larger than 512B.  I'll let that statement trump Norman
> Diamond's until i hear otherwise.

Someone else in this discussion estimated that physical sectors are around
1MB these days.  My friends at Toshiba confirmed that physical sectors are
much larger than logical sectors.  The physical sector size resembles that
1MB estimate far better than the 512B logical sector size.

> The drive manufacturers would like to be able to go to a
> larger physical sector but the read-modify-write is just too
> scary.

It is really hard to imagine a physical sector still being 512B because the
inter-sector gaps would take some huge multiple of the space occupied by the
sectors.  I think this discussion has proved that we need to be scared of
read-modify-writes, but I think the drive manufacturers are doing it even
though it is scary.

> If they could be sure of market acceptance of drives
> that required all I/O to be in larger units they would build
> them because it would allow greater capacity (and i'm
> guessing speed as well) on the same physical hardware.

No, the effect on speed is the opposite.  A simple write could be done with
one seek and a random fraction of a rotational delay.  A read-modify-write
requires one seek and a random fraction plus additional entire rotational
delay.

I want to ask my friends why the read-modify-write behavior changed between
a 512B write and a 4096B write.  When the drive finally reallocated the
defective sector, it was during a 4096B write.  But I don't think they'll be
allowed to answer.  They already weren't allowed to talk much about the
firmware, but they did confirm that my original complaints about the
defective firmware were pretty accurate.

By the way, a few years ago when I visited other departments at Toshiba's
local division, I walked past a lot of ordinary large open-layout offices,
and also walked past one highly secured door.  That door had a sign on it
(in Japanese) saying that entry was prohibited to anyone not working on disk
drive design.  The accidental occurences by which I became friends with some
of their disk drive engineers were not a result of those business visits.
Probably there is no way that Toshiba would ever officially publicize even
the limited amount of information that my friends admitted to.  Nonetheless,
I'm sure the physical sectors are not 512B.

RE: Blockbusting news, results end

[Mudama, Eric]

> -----Original Message-----
> From: Norman Diamond [mailto:ndiamond@wta.att.ne.jp]
>
> The drive finally reallocated the block and there are no 
> longer any visible
> bad blocks.

If a drive wants to reallocate a block, but due to some temporary condition
is unable to (vibration, excessive temperature, etc), odds are there's no
way for that drive to "remember" that it needs to reassign that block, so if
you reboot the drive or reset it or whatever, you're back at square 1.

The only "memory" that survives between power cycles in a disk drive is on
the media, so if we can't reliably access the media we're hosed.

--eric

Re: Blockbusting news, results end

[Norman Diamond]

Eric Mudama wrote:

> If a drive wants to reallocate a block, but due to some temporary
> condition is unable to (vibration, excessive temperature, etc), odds are
> there's no way for that drive to "remember" that it needs to reassign that
> block, so if you reboot the drive or reset it or whatever, you're back at
> square 1.

Bingo.  This is why reallocation at the time of a failed read is also
necessary.  Yes the data are lost, yes the failure needs to be both logged
(once) and displayed to the user (once), yes if an application reads it
again before writing then it will be garbage or zeroes, but get the LBA
sector number moved to a place that is less likely to be unreliable.

Meanwhile software must still make up for defective firmware.

Re: Blockbusting news, results end

[Krzysztof Halasa]

"Norman Diamond" <ndiamond@wta.att.ne.jp> writes:

> Bingo.  This is why reallocation at the time of a failed read is also
> necessary.  Yes the data are lost, yes the failure needs to be both logged
> (once)

The log entry may be easily lost. Especially when the drive is failing.

> and displayed to the user (once),

To which user??? Hard drive sectors have no users.

> yes if an application reads it
> again before writing then it will be garbage or zeroes,

I hope drive makers won't take it seriously.

> but get the LBA
> sector number moved to a place that is less likely to be unreliable.

So you rather want to read garbage than get a real I/O error.
The only situation I can imagine which benefits from such an approach
is playing an audio-video stream.

> Meanwhile software must still make up for defective firmware.

Yeah. yeah. Only "if (drive_is_toshiba()) BUG()" comes to my mind.
-- 
Krzysztof Halasa, B*FH

Re: Blockbusting news, results end

[Norman Diamond]

The drive finally reallocated the block and there are no longer any visible
bad blocks.

I will not be able to perform the following planned test:
  Well, in a future weekend, I will try to see if ext2fs really takes action
  on permanently bad blocks that are detected during normal operations on a
  mounted partition.

But I think the underlying defects remain in need of correction.  Toshiba
knows about theirs but will probably never say if they make any fixes.  Mr.
Reiser and friends have plans to add important features, and I am unable to
detect if ext2fs needs it.  (As mentioned before, I understand that ext2fs
can do it during formatting and fsck, but no one seems to be saying what
happens if a permanently bad block is detected during normal operation on a
mounted partition.)

Re: Blockbusting news, results end

[Pavel Machek]

Hi!

> The drive finally reallocated the block and there are no longer any visible
> bad blocks.

And what was the operation that made it realocate?
									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Blockbusting news, results end

[Norman Diamond]

Pavel Machek replied to me:

> > The drive finally reallocated the block and there are no longer any
> > visible bad blocks.
>
> And what was the operation that made it realocate?

At first I wasn't sure.  I noticed that the drive was behaving differently
when I told dd to use bs=4096 instead of 512.  Until seeing Oleg Drokin's
message about ReiserFS, I thought that the drive itself was doing something
differently.  That didn't make much sense to me because the physical sectors
are much longer than 4096 and the pseudo-sectors are the conventional 512,
so why did 4096 cause different behaviour?  From Oleg Drokin's message, I
guess that the use of 4096 might make a difference in the sequence of
read-modify-write cycles involved in the logical write operation.

This doesn't seem like a complete answer, but I don't think I'll ever know a
complete answer.

Re: Blockbusting news, results end

[jw schultz]

On Sun, Oct 26, 2003 at 08:25:26PM +0900, Norman Diamond wrote:
> Pavel Machek replied to me:
> 
> > > The drive finally reallocated the block and there are no longer any
> > > visible bad blocks.
> >
> > And what was the operation that made it realocate?
> 
> At first I wasn't sure.  I noticed that the drive was behaving differently
> when I told dd to use bs=4096 instead of 512.  Until seeing Oleg Drokin's
> message about ReiserFS, I thought that the drive itself was doing something
> differently.  That didn't make much sense to me because the physical sectors
> are much longer than 4096 and the pseudo-sectors are the conventional 512,
> so why did 4096 cause different behaviour?  From Oleg Drokin's message, I
> guess that the use of 4096 might make a difference in the sequence of
> read-modify-write cycles involved in the logical write operation.

You bring up an interesting point.  If the physical sector
is larger than the data being written how can the drive
reallocate the sector without silently losing data?

To put it in the concrete, if the physical sector were 16K
and we only do a 4K write and there is a unrecoverable read
error on the physical sector as part of the
read-modify-write sequence what is the drive to do?  The
other 12K for which the drive has no data could be other
files not related to the 4K being written or even filesystem
meta-data.  Reallocation in that case would cause silent
corruption.

Perhaps what finally allowed the reallocation was that the
entire physical sector finally accumulated writes to all the
logical sectors needed to be a complete physical sector
write.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Blockbusting news, results end

[Andre Hedrick]

To date IDEMA has not released a formal spec for drive makers to switch to
4Kb sectors.  If they have, then when running in compatibility mode, a
heavy read-modify-write happens to goto the pseudo sector of 512b.

Linux can not handled new IDEMA calls currently.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Mon, 27 Oct 2003, jw schultz wrote:

> On Sun, Oct 26, 2003 at 08:25:26PM +0900, Norman Diamond wrote:
> > Pavel Machek replied to me:
> > 
> > > > The drive finally reallocated the block and there are no longer any
> > > > visible bad blocks.
> > >
> > > And what was the operation that made it realocate?
> > 
> > At first I wasn't sure.  I noticed that the drive was behaving differently
> > when I told dd to use bs=4096 instead of 512.  Until seeing Oleg Drokin's
> > message about ReiserFS, I thought that the drive itself was doing something
> > differently.  That didn't make much sense to me because the physical sectors
> > are much longer than 4096 and the pseudo-sectors are the conventional 512,
> > so why did 4096 cause different behaviour?  From Oleg Drokin's message, I
> > guess that the use of 4096 might make a difference in the sequence of
> > read-modify-write cycles involved in the logical write operation.
> 
> You bring up an interesting point.  If the physical sector
> is larger than the data being written how can the drive
> reallocate the sector without silently losing data?
> 
> To put it in the concrete, if the physical sector were 16K
> and we only do a 4K write and there is a unrecoverable read
> error on the physical sector as part of the
> read-modify-write sequence what is the drive to do?  The
> other 12K for which the drive has no data could be other
> files not related to the 4K being written or even filesystem
> meta-data.  Reallocation in that case would cause silent
> corruption.
> 
> Perhaps what finally allowed the reallocation was that the
> entire physical sector finally accumulated writes to all the
> logical sectors needed to be a complete physical sector
> write.
> 
> -- 
> ________________________________________________________________
> 	J.W. Schultz            Pegasystems Technologies
> 	email address:		jw@pegasys.ws
> 
> 		Remember Cernan and Schmitt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Blockbusting news, results end

[jw schultz]

On Mon, Oct 27, 2003 at 02:27:09PM -0800, Andre Hedrick wrote:
> 
> To date IDEMA has not released a formal spec for drive makers to switch to
> 4Kb sectors.  If they have, then when running in compatibility mode, a
> heavy read-modify-write happens to goto the pseudo sector of 512b.
> 
> Linux can not handled new IDEMA calls currently.

Irrelevant!

I am assuming that these numbers are applicable (one is
unknown):
	logical sector size == 512B
	physical sector size == ???B
	page size/filesystem block size == 4KB

Whether the write of a 4KB block is a single 4KB write or 8
512B writes i expect the drive will gather it so that 4KB is
being written.  If that 4KB (or whatever size write) is less
than the size of a physical sector a read-modify-write cycle
must occur inside the drive.  If the read portion of the
read-modify-write fails the requested write(s) must either fail
or data in the logical sectors adjacent to the write will
become corrupted.  This is whether or not the physical
sector is relocated.

Judging by logic and earlier discussions on the matter of
write errors if that write fails because of a read error in
the read-modify-write to the application it would appear to
have succeeded unless it were synchronous all the way to the
media.

This sounds very much like the described behaviour of the
Toshiba drive that started this whole thread.

To the best of my knowledge we have no way to know what the
physical sector size of a disk is.  For that matter it might
not even be a constant.  Perhaps the someone could inform us
what the drive will actually do if the read portion of a
read-modify-write fails.

> 
> Cheers,
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 
> On Mon, 27 Oct 2003, jw schultz wrote:
> 
> > On Sun, Oct 26, 2003 at 08:25:26PM +0900, Norman Diamond wrote:
> > > Pavel Machek replied to me:
> > > 
> > > > > The drive finally reallocated the block and there are no longer any
> > > > > visible bad blocks.
> > > >
> > > > And what was the operation that made it realocate?
> > > 
> > > At first I wasn't sure.  I noticed that the drive was behaving differently
> > > when I told dd to use bs=4096 instead of 512.  Until seeing Oleg Drokin's
> > > message about ReiserFS, I thought that the drive itself was doing something
> > > differently.  That didn't make much sense to me because the physical sectors
> > > are much longer than 4096 and the pseudo-sectors are the conventional 512,
> > > so why did 4096 cause different behaviour?  From Oleg Drokin's message, I
> > > guess that the use of 4096 might make a difference in the sequence of
> > > read-modify-write cycles involved in the logical write operation.
> > 
> > You bring up an interesting point.  If the physical sector
> > is larger than the data being written how can the drive
> > reallocate the sector without silently losing data?
> > 
> > To put it in the concrete, if the physical sector were 16K
> > and we only do a 4K write and there is a unrecoverable read
> > error on the physical sector as part of the
> > read-modify-write sequence what is the drive to do?  The
> > other 12K for which the drive has no data could be other
> > files not related to the 4K being written or even filesystem
> > meta-data.  Reallocation in that case would cause silent
> > corruption.
> > 
> > Perhaps what finally allowed the reallocation was that the
> > entire physical sector finally accumulated writes to all the
> > logical sectors needed to be a complete physical sector
> > write.
> > 
> > -- 
> > ________________________________________________________________
> > 	J.W. Schultz            Pegasystems Technologies
> > 	email address:		jw@pegasys.ws
> > 
> > 		Remember Cernan and Schmitt
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Blockbusting news, results end

[jw schultz]

On Mon, Oct 27, 2003 at 02:57:27PM -0800, jw schultz wrote:
> On Mon, Oct 27, 2003 at 02:27:09PM -0800, Andre Hedrick wrote:
> > 
> > To date IDEMA has not released a formal spec for drive makers to switch to
> > 4Kb sectors.  If they have, then when running in compatibility mode, a
> > heavy read-modify-write happens to goto the pseudo sector of 512b.
> > 
> > Linux can not handled new IDEMA calls currently.
> 
> Irrelevant!

Andre, if you were trying to say what i am about to, i
apologise.

> I am assuming that these numbers are applicable (one is
> unknown):
> 	logical sector size == 512B
> 	physical sector size == ???B
> 	page size/filesystem block size == 4KB

I have dialoged with Eric Mudama.  He is 99% sure that no
manufacturer of is making ATA drives with physical sectors
larger than 512B.  I'll let that statement trump Norman
Diamond's until i hear otherwise.

The drive manufacturers would like to be able to go to a
larger physical sector but the read-modify-write is just too
scary.  If they could be sure of market acceptance of drives
that required all I/O to be in larger units they would build
them because it would allow greater capacity (and i'm
guessing speed as well) on the same physical hardware.
I look forward to the day with Linux has enough market-share
to influence the hardware manufacturers.

In any case, unless someone can authoritatively contradict
Eric we can ignore the firmware read-modify-write
implications of unreadable sectors.

End-of-subthread!
or in the words of Emily Latella "Never-mind".

Re: Blockbusting news, results end

[Hans Reiser]

Norman Diamond wrote:

>The drive finally reallocated the block and there are no longer any visible
>bad blocks.
>
>I will not be able to perform the following planned test:
>  Well, in a future weekend, I will try to see if ext2fs really takes action
>  on permanently bad blocks that are detected during normal operations on a
>  mounted partition.
>
>But I think the underlying defects remain in need of correction.  Toshiba
>knows about theirs but will probably never say if they make any fixes.  Mr.
>Reiser and friends have plans to add important features, and I am unable to
>detect if ext2fs needs it.  (As mentioned before, I understand that ext2fs
>can do it during formatting and fsck, but no one seems to be saying what
>happens if a permanently bad block is detected during normal operation on a
>mounted partition.)
>
>
>
>  
>
Badblocks support is in reiser4, and anyone is welcome to update the 
patch for V3, or sponsor us to do it.  We are very low on cash, so we 
only work on V4, as that is the only way it will get to ship.

-- 
Hans

Re: Blockbusting news, results end

[Oleg Drokin]

Hans Reiser <reiser@namesys.com> wrote:

HR> Badblocks support is in reiser4, and anyone is welcome to update the 
HR> patch for V3, or sponsor us to do it.  We are very low on cash, so we 

Actually that v3 patch does not do bad blocks remapping in case of
write failure, it only does remapping when you manually ask it.
And biggest part of badblocks support in reiser3 is in reiserfsck and tools
(and in not that bad shape, last time I looked).
As for remapping bad blocks on write failure, the only PC OS that was doing
this that comes to my mind is Novell Netware (I think they called it a "hotfix"
or something like that).

Bye,
    Oleg

Re: Blockbusting news, results end

[Hans Reiser]

Oleg Drokin wrote:

>Hans Reiser <reiser@namesys.com> wrote:
>
>HR> Badblocks support is in reiser4, and anyone is welcome to update the 
>HR> patch for V3, or sponsor us to do it.  We are very low on cash, so we 
>
>Actually that v3 patch does not do bad blocks remapping in case of
>write failure, it only does remapping when you manually ask it.
>And biggest part of badblocks support in reiser3 is in reiserfsck and tools
>(and in not that bad shape, last time I looked).
>As for remapping bad blocks on write failure, the only PC OS that was doing
>this that comes to my mind is Novell Netware (I think they called it a "hotfix"
>or something like that).
>
>Bye,
>    Oleg
>
>
>  
>
I wasn't saying we would do what is in Netware, and as far as being in 
bad shape is concerned, from the user's point of view it either works or 
it doesn't.

-- 
Hans

Re: Blockbusting news, results end

[Oleg Drokin]

Hello!

On Sun, Oct 26, 2003 at 03:05:04PM +0300, Hans Reiser wrote:
> >HR> Badblocks support is in reiser4, and anyone is welcome to update the 
> >HR> patch for V3, or sponsor us to do it.  We are very low on cash, so we 
> >Actually that v3 patch does not do bad blocks remapping in case of
> >write failure, it only does remapping when you manually ask it.
> >And biggest part of badblocks support in reiser3 is in reiserfsck and tools
> >(and in not that bad shape, last time I looked).
> >As for remapping bad blocks on write failure, the only PC OS that was doing
> >this that comes to my mind is Novell Netware (I think they called it a 
> >"hotfix"
> >or something like that).
> I wasn't saying we would do what is in Netware, and as far as being in 

Sure, I was not claiming this either, but original man seems to be implying
such a feature as something common.

> bad shape is concerned, from the user's point of view it either works or 
> it doesn't.

Sure. And in modern desktop world it does not work (if SMART does not want to
do it).

Bye,
    Oleg

Re: Blockbusting news, results end

[Hans Reiser]

Oleg Drokin wrote:

>
>  
>
>>bad shape is concerned, from the user's point of view it either works or 
>>it doesn't.
>>    
>>
>
>Sure. And in modern desktop world it does not work (if SMART does not want to
>do it).
>
>Bye,
>    Oleg
>
>
>  
>

I don't understand what SMART has to do with it.  I was talking about a 
patch is either ready for use, or it isn't, and "almost ready" is worthless.

-- 
Hans

Re: Blockbusting news, results end

[Oleg Drokin]

Hello!

On Sun, Oct 26, 2003 at 07:26:38PM +0300, Hans Reiser wrote:
> >>bad shape is concerned, from the user's point of view it either works or 
> >>it doesn't.
> >Sure. And in modern desktop world it does not work (if SMART does not want 
> >to
> >do it).
> I don't understand what SMART has to do with it.  I was talking about a 
> patch is either ready for use, or it isn't, and "almost ready" is worthless.

Ah. Last time I checked, patch was ready to use.
But it is not strictly necessary, the reason of the patch was to mark bad blocks
in mounted filesystems "on the fly". Everything else should be handled
by reiserfsprogs anyway. Without reiserfsprogs support (which was ready too),
it is worthless.

Bye,
    Oleg

Re: Blockbusting news, results end

[Hans Reiser]

> Everything else should be handled
>by reiserfsprogs anyway. Without reiserfsprogs support (which was ready too),
>  
>
If it isn't included in what we release, the job isn't done, and the 
work is useless.  I don't know why people think that if they have 
written a patch that they and only they know where to get and how to 
apply, something useful has been done.



-- 
Hans

Re: Blockbusting news, results end

[Oleg Drokin]

Hello!

On Sun, Oct 26, 2003 at 09:20:45PM +0300, Hans Reiser wrote:
> >Everything else should be handled
> >by reiserfsprogs anyway. Without reiserfsprogs support (which was ready 
> >too),
> If it isn't included in what we release, the job isn't done, and the 
> work is useless.  I don't know why people think that if they have 
> written a patch that they and only they know where to get and how to 
> apply, something useful has been done.

The kernel patch was handed to Vitaly with instructions on how to apply and
how to use. (And Vitaly added necessary support to reiserfsprogs, without
which this patch would be useless)
Now the decision of whenever to release this piece of code (the patch and
the reiserfsprogs parts) is not mine.

Bye,
    Oleg

Re: Blockbusting news, results end

[Vitaly Fertman]

On Sunday 26 October 2003 22:07, Oleg Drokin wrote:
> Hello!
>
> On Sun, Oct 26, 2003 at 09:20:45PM +0300, Hans Reiser wrote:
> > >Everything else should be handled
> > >by reiserfsprogs anyway. Without reiserfsprogs support (which was ready
> > >too),
> >
> > If it isn't included in what we release, the job isn't done, and the
> > work is useless.  I don't know why people think that if they have
> > written a patch that they and only they know where to get and how to
> > apply, something useful has been done.
>
> The kernel patch was handed to Vitaly with instructions on how to apply and
> how to use. (And Vitaly added necessary support to reiserfsprogs, without
> which this patch would be useless)
> Now the decision of whenever to release this piece of code (the patch and
> the reiserfsprogs parts) is not mine.

The code needed to be tested first before releasing, it is done by now and
I am about to put on our ftp site 3.6.12-pre1 release with this bad block support.

-- 
Thanks,
Vitaly Fertman