giving up on 1 buffers error messsage

[João Carlos Mendes Luís]

Although I am not exactly an expert on the field, I'll try to explain.

The disk write procedures should wait for the disk to be ready, and this 
involves (soft)interrupts.  When rebooting, the system can only wait for 
the device drivers to empty the write buffers, since it is not in 
interrupt context.

If, for some reason, a disk device does not empty its buffer after some 
time, you will receive this "give up" message.  In your case, one last 
buffer did not get to its destination, but 53 did.

I get this message mostly on hard disk failures or panics related to 
disk devices.

Note that sync will not solve the problem.  What sync does is exactly 
what the reboot is doing: asks the system to empty its buffers.  The 
only difference is that sync() does not wait for return.  Indeed, this 
was the behaviour on pre-softupdate ages, this may not be true anymore. 
   ;-)

Andriy Tkachuk wrote:
> It is interesting why threre is no answer for this question so long time,
> regardless that it was posted 2 times :)
> 
> For me it is also interesting to get the answer for this question
> since from time to time i also confused by such msgs on
> shutdown.
> 
> 
>>syncing disks... 54 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1
>>buffers
>>
>>
>>Hi,
>>
>>I am referring to the message when the code in kern_shutdown.c in bsd
>>4.10 is called at the time of boot() system call
>>
>>My understanding is that this message tells us that 1 buffer from the
>>buffer cache was not successfully flushed to disk, since the last call to
>>sync(). Is that right? In that case what happens to this buffer? Is it
>>discarded and assume that fsck will fix this on reboot?
>>
>>Since the syncer process runs periodically, can this error message be
>>avoided if we wait long enough to guarantee flushing to disk (I have tried
>>with DELAYS upto 30 seconds but I still get the error sometimes).
>>
>>I am actually trying to use this same code at a different point in time
>>(not during shutdown, but to take a checkpoint), so I am not sure if that
>>contributes to this error message?
>>
>>
>>
>>
>>_______________________________________________
>>freebsd-hackers at freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>>
>>
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"


                                         Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br