BIND 10 #1704: log output mixed

[BIND 10 Development]

#1704: log output mixed
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:
                       Type:         |                Status:  new
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120403
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  15
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 I don't think this is completely true. The write indeed is atomic. But
 imagine the kernel has a writeback buffer of certain size. The buffer is
 for example 4096 bytes long (well, it will be more, but anyway). And it so
 happened someone was busy logging and filled 4090 bytes already and the
 buffer was not flushed to disk yet, because it takes several milliseconds
 to seek there (or to send it over the ssh on a slow network, or whatever).
 So we now call our write with 10 bytes, but only 6 fit. So these 6 are put
 to the buffer (atomically) and the write returns immediately, doing a
 partial write. So we retry with the 4 bytes that we have left (and block).
 Once a 512 block of the buffer is written to the disk, and the kernel
 takes one of the writes now waiting, which might be the write of ours with
 4 bytes or a completely different write with a complete message from
 someone else, puts it (atomically) to the end of the buffer and picks
 another write waiting.

 The exact sizes can be expected to be much more on modern linux with huge
 amount of memory and SATA disks with several-megabytes of internal caches
 and 4k sized blocks, etc, which makes the situation less probable (which
 might be the reason I never saw it myself, or maybe because I don't store
 it to disk and my urxvtd is able to eat data really fast from the pipe),
 but it is said there are systems with less memory or older disks or
 different kernels or something…

 The magic I have in mind (if it exists) was to prevent this situation
 somehow.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1704#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development