Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
> >As of a write-protected floppy, why is it allowd to be mounted as > >writeable? > >The mount should be degraded to readonly or rejected. This would not be very convenient - a person may want to remove the write protection without remounting the floppy. 28.10.2002; 18:14:52 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
> :The output signals don't go straight from the chip - do they? > :I've seen few KOhms resistors on most boards for each output pin. > An external series resistor is there strictly for current > limiting purposes. Yep, that's why I asked if manufacturers usually put external resistors. I tried to short all the wires together and on the ground :) from an old ISA paraller port controller card - it didn't blow up. So the message to the author of this thread: check for resistors on your mboard, if it's the old one, in series with the outputs, so that you can be sure that you won't kill the controller during experiments... 28.10.2002; 18:05:15 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk reliability (was: Tagged Command Queuing or Larger Cache?)
On Wed, 30 Oct 2002, Greg 'groggy' Lehey wrote: > On Tuesday, 29 October 2002 at 2:03:50 +, Daniel O'Connor wrote: > > On Tue, 2002-10-29 at 01:54, Kenneth Culver wrote: > >>> I haven't had any trouble with the WDxxxBB drives - the WDxxxAA drives > >>> are pretty unreliable though. > >>> > >> Hrmm, I havn't tried those, but just about every WD drive I've used has > >> ended up with problems which were of course handled by the warranty, but > >> even then, I still had to reinstall the os and pull a bunch of stuff from > >> my backups which was a pain to do for each failure. Like I said, just my > >> personal experience. I don't think the new 8MB cache drives have been out > >> long enough to actually develop the problems I've seen on WD drives > >> though. > > > > Yes, but my point is that the AA drives are bad, but the BB drives seem > > good. I have been using them for a while (~1 year) without trouble. > > I've had trouble with BB drives. Given that they have (or had) a 3 > year warranty, 1 year of experience isn't very much to go by. > > > Personally I find that no HD manufacturer has a good reputation - > > they have all made trashy drives at one point. Give the general time > > it takes for problems to surface vs product lifetimes makes deciding > > what to buy a PITA :( > > That's a more valid point. > > Note that WD and Seagate have dropped their warranty on IDE drives > from 3 years to 1 year. What does this say to you? Hmmm, from what I remember, they did that for the 5400RPM drives, not the 7200RPM drives! Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], http://www.richardsharpe.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
David Schultz wrote: > Thus spake Peter Wemm <[EMAIL PROTECTED]>: > > Actually, not even then. Modern IDE drives only write entire tracks at a > > time. If you modify a single sector, then the drive has to read the entire > > track into the buffer, in-place edit the sector, and then rewrite the entir e > > track. > [...] > > And that completely blows FFS's assumptions out of the water. And what > > is sad is that many SCSI disks are similar these days. But not all of > > them (I'm told). > > I've heard this before. It would be very useful to have > information about which drives have this misfeature, but I guess > it isn't the sort of thing that hard drive manufacturers like to > advertise. Does anyone have any data on track-writing drives? IBM used to claim it as a feature and have patents on it. As best as I can tell, all IDE disks have it since about 1999 or so. Quantum and IBM certainly did, as it was a way of getting the drive capacity up and reducing the cost. One way that you can tell is by seeing how big the slowdown is when write caching is turned off and whether you see the same slowdown slowdown regardless of any sector interleaving. ie: if writing to every 10th or 20th (or whatever) sector is just as slow as writing to every sector with write caching turned off, then you have a track-write drive. This is because every single sector write causes the entire track to be written. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk reliability (was: Tagged Command Queuing or Larger Cache ?)
On Wed, 2002-10-30 at 10:59, Greg 'groggy' Lehey wrote: > I've had trouble with BB drives. Given that they have (or had) a 3 What trouble? > year warranty, 1 year of experience isn't very much to go by. Hah, well not anymore.. I agree with your assessment about 1 vs 3 years, but as I said below it is basically impossible to know in advance. > > Personally I find that no HD manufacturer has a good reputation - > > they have all made trashy drives at one point. Give the general time > > it takes for problems to surface vs product lifetimes makes deciding > > what to buy a PITA :( > > That's a more valid point. > > Note that WD and Seagate have dropped their warranty on IDE drives > from 3 years to 1 year. What does this say to you? You can buy JB drives which have both a larger cache and a longer warranty. You can also purchase an extended warranty (but it costs about the same as the price difference between the BB and JB drives) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Disk reliability (was: Tagged Command Queuing or Larger Cache ?)
On Tuesday, 29 October 2002 at 2:03:50 +, Daniel O'Connor wrote: > On Tue, 2002-10-29 at 01:54, Kenneth Culver wrote: >>> I haven't had any trouble with the WDxxxBB drives - the WDxxxAA drives >>> are pretty unreliable though. >>> >> Hrmm, I havn't tried those, but just about every WD drive I've used has >> ended up with problems which were of course handled by the warranty, but >> even then, I still had to reinstall the os and pull a bunch of stuff from >> my backups which was a pain to do for each failure. Like I said, just my >> personal experience. I don't think the new 8MB cache drives have been out >> long enough to actually develop the problems I've seen on WD drives >> though. > > Yes, but my point is that the AA drives are bad, but the BB drives seem > good. I have been using them for a while (~1 year) without trouble. I've had trouble with BB drives. Given that they have (or had) a 3 year warranty, 1 year of experience isn't very much to go by. > Personally I find that no HD manufacturer has a good reputation - > they have all made trashy drives at one point. Give the general time > it takes for problems to surface vs product lifetimes makes deciding > what to buy a PITA :( That's a more valid point. Note that WD and Seagate have dropped their warranty on IDE drives from 3 years to 1 year. What does this say to you? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Command used to trace the stack of a process
l *routine + 0x350 or if you use a core file with symbols (-g), gdb will do it automatically. Please read the gdb docs for better info. On Tue, 29 Oct 2002, Zhihui Zhang wrote: > > Thanks. The backtrace often gives something like: > > + 0x350 > > Is there a way to quickly determine the correponding source code line? > > -Zhihui > > On Tue, 29 Oct 2002, Nate Lawson wrote: > > > On Tue, 29 Oct 2002, John Baldwin wrote: > > > On 29-Oct-2002 Zhihui Zhang wrote: > > > > > > > > I remember there is a command in either gdb or ddb which enable you to > > > > display the stack of a particular process. Can anyone tell me if there is > > > > such a command and what the command is? Thanks! > > > > > > In ddb you can do 'tr ' where is the PID of the process. > > > > In gdb, it's bt. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Command used to trace the stack of a process
Thanks. The backtrace often gives something like: + 0x350 Is there a way to quickly determine the correponding source code line? -Zhihui On Tue, 29 Oct 2002, Nate Lawson wrote: > On Tue, 29 Oct 2002, John Baldwin wrote: > > On 29-Oct-2002 Zhihui Zhang wrote: > > > > > > I remember there is a command in either gdb or ddb which enable you to > > > display the stack of a particular process. Can anyone tell me if there is > > > such a command and what the command is? Thanks! > > > > In ddb you can do 'tr ' where is the PID of the process. > > In gdb, it's bt. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: > >Recently? I know that the bug was present at least six months > >ago, and probably earlier as well. > > That's "recently" enough for me :-) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe ^^ Ah yes, I should have guessed. Do you happen to know at what point it was non-broken? The problem seems nontrivial to fix, given that you have to be able to propagate the failure up to the filesystem and cancel all dependent metadata updates in order to maintain correctness. That's why it seems easier to me to just destory the failed buffers on unmount, but maybe I'm missing something. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
Hanspeter Roth wrote: > On Oct 29 at 18:34, Poul-Henning Kamp spoke: > > That's a slightly more involved issue because you would have to > > actually try to write to it before you find out that you can't. > > Isn't there a means to determine the state of the protection before > the mount is attempted? You can write 0x04ss (sense drive status on standard parameter for drive and head select 'ss') to port 0x03F5; then read disk status register 3 for one byte: bit meaning --- 7 No drive fault 6 Write protected (1 = protected) 5 Drive ready (1 = ready) 4 Head is on track zero (1 = on track 0) 3 Two sided (1 = two sided, 0 = one sided) 2 Head select (0 = side 0, 1 = side 1) 1 | 0 | bit 1 bit 0 meaning - - 0 0 drive 0 selected 0 1 drive 1 selected 1 0 drive 2 selected 1 1 drive 3 selected You can detect "disk change" by selecting a sidk, and then reading 0x03F7 (this works on all PC hardware on or after the IBM PC AT). The byte you read is only interesting for bit 7, unless you can verify that specific controller being used. If bit 7 is zero, then there is a disk present, and it has not been changed. If bit 7 is set, then there is no diskette present, or the disk has not been changed. Therefore, by repeating this operation twice, and seeing a 1 -> 0 transition for bit 7, you can tell a disk is present, or seeing a 1 -> 1 persistance, you can tell there is no disk present (e.g. you will need to save "one behind" on status for this to be useful in detecting both changes and missing disks). Note that this works on 3.5" disks, but only works on 5.25" disks that are 1.2M or larger. In addition, many systems fail to wire up the "disk change" or "disk present" lines from the floppy drive to the controller, hard wiring the disk as being present and unchanged at all times. So "disk change" is unreliable. "If all else fails, read the documentation..." -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Command used to trace the stack of a process
On Tue, 29 Oct 2002, John Baldwin wrote: > On 29-Oct-2002 Zhihui Zhang wrote: > > > > I remember there is a command in either gdb or ddb which enable you to > > display the stack of a particular process. Can anyone tell me if there is > > such a command and what the command is? Thanks! > > In ddb you can do 'tr ' where is the PID of the process. In gdb, it's bt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
On Mon, 28 Oct 2002, Doug Barton wrote: > On Mon, 28 Oct 2002, Kenneth Culver wrote: > > > > I'd probably steer clear of the western digital drives as well. Yes the > > > > make that "stear" clear. > > Ummm... why? "steer" is a word with multiple meanings. I can't find > "stear" anywhere. Mu. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, David Schultz writes: >Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: >> In message <[EMAIL PROTECTED]>, David Schultz writes: >> >> >IMO, the retry-forever bug is the >> >real problem, but I'm a bit skeptical that it's easy to solve >> >safely. >> >> Just revert the commit which added it recently. > >Recently? I know that the bug was present at least six months >ago, and probably earlier as well. That's "recently" enough for me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: > In message <[EMAIL PROTECTED]>, David Schultz writes: > > >IMO, the retry-forever bug is the > >real problem, but I'm a bit skeptical that it's easy to solve > >safely. > > Just revert the commit which added it recently. Recently? I know that the bug was present at least six months ago, and probably earlier as well. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
help To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
:The output signals don't go straight from the chip - do they? :I've seen few KOhms resistors on most boards for each output pin. : :27.10.2002; 19:32:00 :[SorAlx] http://cydem.zp.ua/ It depends on the chip. Most modern serial driver chips have series resistors on the outputs, inside the chip, and do not need any external current limiting (which is what the resistor does in effect). Parallel port chips typically do not have output resistors and instead depend on beefy TTL output stages, and a good motherboard manufacturer will put series resistors on those pins. All modern chips have diode protection on their outputs but you can still zap them (static shock it to death). Serial pins tend to be far, far more robust then parallel port pins due to having to go through level converters to get the right voltages on outputs and to be able to handle +/-12V on inputs. For example, most serial driver chips can handle up to +/-25V on their inputs before they blow up. Try putting even +12V on a parallel port pin and you will likely fry the chip, even with an external series resistor, and an external series resistor alone will not stop a big static shock, only a Zener diode is fast enough to do that. An external series resistor is there strictly for current limiting purposes. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, David Schultz writes: >IMO, the retry-forever bug is the >real problem, but I'm a bit skeptical that it's easy to solve >safely. Just revert the commit which added it recently. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: > >Isn't there a means to determine the state of the protection before > >the mount is attempted? > > As far as I know there isn't. I'm not sure if it is a device driver > (morituri te salutem!) or hardware issue. I believe most floppy drives can be queried for both their write-protect status and whether the inserted disk has been changed. If someone cared enough, these bits could be used to protect users from themselves. IMO, the retry-forever bug is the real problem, but I'm a bit skeptical that it's easy to solve safely. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
On Tue Oct 29, 2002 at 06:47:24PM +0100, Hanspeter Roth wrote: > > Isn't there a means to determine the state of the protection before > the mount is attempted? No. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, Hanspeter Roth writes: > On Oct 29 at 18:34, Poul-Henning Kamp spoke: > >> That's a slightly more involved issue because you would have to >> actually try to write to it before you find out that you can't. > >Isn't there a means to determine the state of the protection before >the mount is attempted? As far as I know there isn't. I'm not sure if it is a device driver (morituri te salutem!) or hardware issue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
On Oct 29 at 18:34, Poul-Henning Kamp spoke: > That's a slightly more involved issue because you would have to > actually try to write to it before you find out that you can't. Isn't there a means to determine the state of the protection before the mount is attempted? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, Hanspeter Roth writes: > On Oct 18 at 20:45, Maxim Sobolev spoke: > >> again, then again ad infinitum. The same effect if you'll mount >> write-protected floppy in read/write mode. This is just lame, but I'm not willing to to take a shouting match with the person who committed this brain-damage. >As of a write-protected floppy, why is it allowd to be mounted as >writeable? >The mount should be degraded to readonly or rejected. That's a slightly more involved issue because you would have to actually try to write to it before you find out that you can't. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
On Oct 18 at 20:45, Maxim Sobolev spoke: > again, then again ad infinitum. The same effect if you'll mount > write-protected floppy in read/write mode. As of a write-protected floppy, why is it allowd to be mounted as writeable? The mount should be degraded to readonly or rejected. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Command used to trace the stack of a process
On 29-Oct-2002 Zhihui Zhang wrote: > > I remember there is a command in either gdb or ddb which enable you to > display the stack of a particular process. Can anyone tell me if there is > such a command and what the command is? Thanks! In ddb you can do 'tr ' where is the PID of the process. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Command used to trace the stack of a process
Is /usr/ports/sysutils/pstack what you're looking for? -- Peter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
On Tue, Oct 29, 2002 at 05:08:45PM +0100, Bernd Walter wrote:
> On Mon, Oct 28, 2002 at 08:56:35AM -0500, Joe Sunday wrote:
> > On Sun, Oct 27, 2002 at 09:12:33AM -0800, David Nicholas Kayal wrote:
> >
> > > I'm looking for a 5 volt signal.
> > >
> > > I have wires plugged into pins 2 and 25 of the parallel port.
> > >
> > > I have written a small program:
> > >
> > > #include
> > > #include
> > > #include
> > >
> > > int main()
> > > {
> > > int fd;
> > > while(1)
> > > {
> > > ioctl(fd, PPISDATA, 255);
> > > }
> > > }
> >
> > PPISDATA actually takes an int* argument. (The man page may be a tad
> > confusing here.)
>
> No it takes an u_int8_t* exactly as written in the manpage.
> Using an int doesn't work in all cases.
> I have no idea what part of the manpage is confusing.
>
> > Try
> > int main() {
> > int fd;
> > int d = 255;
> u_int8_t d = 255;
>
> > fd = open( "/dev/ppi0", O_RDWR );
> >
> > ioctl( fd, PPISDATA, &d );
> >
> > return 0;
> > }
My bad. Yeah, it takes a u_int8_t* argument, not an int* (Serves me right for
doing it off the top of my head instead of looking at my code). However,
the original poster had it simply taking some integer value rather than
a pointer.
The man page says this:
Each command takes a single u_int8_t argument, transferring one
byte of data.
Which, to me at first glance, can read as a u_int8_t argument, rather
than a u_int8_t* argument if you're new to using ioctls. The example
further down the man page has it properly taking an pointer.
--Joe
--
Joe Sunday <[EMAIL PROTECTED]> http://www.csh.rit.edu/~sunday/
Computer Science House, Rochester Inst. Of Technology
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
On Mon, Oct 28, 2002 at 08:56:35AM -0500, Joe Sunday wrote:
> On Sun, Oct 27, 2002 at 09:12:33AM -0800, David Nicholas Kayal wrote:
>
> > I'm looking for a 5 volt signal.
> >
> > I have wires plugged into pins 2 and 25 of the parallel port.
> >
> > I have written a small program:
> >
> > #include
> > #include
> > #include
> >
> > int main()
> > {
> > int fd;
> > while(1)
> > {
> > ioctl(fd, PPISDATA, 255);
> > }
> > }
>
> PPISDATA actually takes an int* argument. (The man page may be a tad
> confusing here.)
No it takes an u_int8_t* exactly as written in the manpage.
Using an int doesn't work in all cases.
I have no idea what part of the manpage is confusing.
> Try
> int main() {
> int fd;
> int d = 255;
u_int8_t d = 255;
> fd = open( "/dev/ppi0", O_RDWR );
>
> ioctl( fd, PPISDATA, &d );
>
> return 0;
> }
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Command used to trace the stack of a process
I remember there is a command in either gdb or ddb which enable you to display the stack of a particular process. Can anyone tell me if there is such a command and what the command is? Thanks! -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
Thus spake Peter Wemm <[EMAIL PROTECTED]>: > Actually, not even then. Modern IDE drives only write entire tracks at a > time. If you modify a single sector, then the drive has to read the entire > track into the buffer, in-place edit the sector, and then rewrite the entire > track. [...] > And that completely blows FFS's assumptions out of the water. And what > is sad is that many SCSI disks are similar these days. But not all of > them (I'm told). I've heard this before. It would be very useful to have information about which drives have this misfeature, but I guess it isn't the sort of thing that hard drive manufacturers like to advertise. Does anyone have any data on track-writing drives? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
