Hello, Poul-Henning Kamp!
On Tue, Oct 29, 2002 at 09:32:13PM +0100, you wrote:
> >> >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 prese
On Tue, Oct 29, 2002 at 06:34:36PM +0100, Poul-Henning Kamp wrote:
> 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.
>
> Th
> >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://cyde
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 sin
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 atte
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 rever
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
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] | TC
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
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
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 protect
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 Unsubscrib
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
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
Poul-Henning Kamp wrote:
> Yes, I noticed that appeared at some time. That misfeature should be
> removed in toto.
>
> If a retry can solve the issue, it's the drivers responsibility to
> retry as much as makes sense and then fail if it doesn't work.
>
> Neither the buf nor the bio layer should
In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
>Hi folks,
>
>I noticed that FreeBSD buf/bio subsystem has one very annoying problem
>- once the write request is ejected into it, and write operation
>failed, there seemingly no way valid to tell the layer to drop the
>buffer. Instead, it retr
Matthew Dillon wrote:
> :Hmm, the current approach doesn't look all that "right" to me, because we are
> :retrying operation even though the upper-layer code that initiated it was
> :already notified about the failure (e.g. received EIO), so that it should not
> :assume that the data was actually w
On Fri, Oct 18, 2002 at 11:35:54AM -0700, Matthew Dillon wrote:
>
> :> :
> :> :There is a very easy way to trigger the problem: insert blank floppy
> :> :...
> :>
> :> Your patch looks slightly incomplete to me, but the concept is reasonable.
> :> The BIO_NORETRY test that sets B_INVAL sh
:> :
:> :There is a very easy way to trigger the problem: insert blank floppy
:> :...
:>
:> Your patch looks slightly incomplete to me, but the concept is reasonable.
:> The BIO_NORETRY test that sets B_INVAL should probably be done in
:> brelse(), not in bufwait(). It is the code in
Matthew Dillon wrote:
>
> :Hi folks,
> :
> :I noticed that FreeBSD buf/bio subsystem has one very annoying problem
> :- once the write request is ejected into it, and write operation
> :failed, there seemingly no way valid to tell the layer to drop the
> :buffer. Instead, it retries the attempt ov
:Hi folks,
:
:I noticed that FreeBSD buf/bio subsystem has one very annoying problem
:- once the write request is ejected into it, and write operation
:failed, there seemingly no way valid to tell the layer to drop the
:buffer. Instead, it retries the attempt over and over again, until
:reboot, eve
Hi folks,
I noticed that FreeBSD buf/bio subsystem has one very annoying problem
- once the write request is ejected into it, and write operation
failed, there seemingly no way valid to tell the layer to drop the
buffer. Instead, it retries the attempt over and over again, until
reboot, even thoug
22 matches
Mail list logo
