Re: giving up on 1 buffers error messsage
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: giving up on 1 buffers error messsage
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Jonny -- João Carlos Mendes Luís - Networking Engineer - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
giving up on 1 buffers error messsage
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
giving up on 1 buffers error messsage
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
