{"id":6361,"date":"2011-12-05T16:26:40","date_gmt":"2011-12-05T16:26:40","guid":{"rendered":"http:\/\/www.beautifulwork.org\/?p=6361"},"modified":"2011-12-05T16:26:40","modified_gmt":"2011-12-05T16:26:40","slug":"patch-15-writeback-fix-issue-on-make-htmldocs","status":"publish","type":"post","link":"https:\/\/www.trueangle.org\/index.php\/2011\/12\/05\/patch-15-writeback-fix-issue-on-make-htmldocs\/","title":{"rendered":"fs: Make write(2) interruptible by a fatal signal"},"content":{"rendered":"
\nKernel Space\nlinux-fsdevel@vger.kernel.org :\n\n\nCurrently write(2)  to a file  is not interruptible by  any signal.\nSometimes this is  desirable, e.g. when you want  to quickly kill a\nprocess  hogging your  disk. Also,  with commit  499d05ecf990 (\"mm:\nMake  task in balance_dirty_pages()  killable\"), it's  necessary to\nabort the  current write accordingly  to avoid it  quickly dirtying\nlots more pages at unthrottled rate.\n\nbalance_dirty_pages_ratelimited_nr - balance dirty memory state\n\nProcesses which  are dirtying memory  should call in here  once for\neach page which was  newly dirtied.  The function will periodically\ncheck  the system's  dirty  state and  will  initiate writeback  if\nneeded.  On really  big machines, get_writeback_state is expensive,\nso try to avoid calling it too often (ratelimiting). But once we're\nover the dirty memory limit  we decrease the ratelimiting by a lot,\nto  prevent individual  processes  from overshooting  the limit  by\n(ratelimit_pages) each.\n\nClassroom\n\nA memory-mapped file is a  segment of virtual memory which has been\nassigned a direct byte-for-byte  correlation with some portion of a\nfile or file-like resource. This  resource is typically a file that\nis physically  present on-disk,  but can also  be a  device, shared\nmemory  object,  or  other   resource  that  the  operating  system\ncanreference  through   a  file  descriptor.   Once  present,  this\ncorrelation  between   the  file  and  the   memory  space  permits\napplications  to treat  the mapped  portion as  if it  were primary\nmemory.\n\n\nsource: http:\/\/en.wikipedia.org\/wiki\/Memory-mapped_file\n\nUser Space\nwrite - write to a file descriptor\n\n\nA successful return  from write() does not make  any guarantee that\ndata  has  been  committed  to   disk.   In  fact,  on  some  buggy\nimplementations,  it  does  not   even  guarantee  that  space  has\nsuccessfully been reserved  for the data.  The only  way to be sure\nis to call fsync(2) after you are done writing all your data.  If a\nwrite() is  interrupted by  a signal handler  before any  bytes are\nwritten,  then  the call  fails  with the  error  EINTR;  if it  is\ninterrupted  after at  least one  byte has  been written,  the call\nsucceeds, andreturns the number of bytes written.\n\n\nfsync, fdatasync - synchronize a file's in-core state with storage device\n\nfsync() transfers  (\"flushes\") all modified in-core  data of (i.e.,\nmodified buffer cache  pages for) the file referred  to by the file\ndescriptor  fd  to the  disk  device  (or  other permanent  storage\ndevice) where that file resides.   The call blocks until the device\nreports that the transfer  has completed.  It also flushes metadata\ninformation  associated  with  the  file  (see  stat(2)).   Calling\nfsync() does not necessarily ensure that the entry in the directory\ncontaining the  file has also  reached disk.  For that  an explicit\nfsync() on a file descriptor for the directory is also needed.\n\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Kernel Space linux-fsdevel@vger.kernel.org : Currently write(2) to a file is not interruptible by any signal. Sometimes this is desirable, e.g. when you want to quickly kill a process hogging your disk. Also, with commit 499d05ecf990 (“mm: Make task in balance_dirty_pages() killable”), it’s necessary to abort the current write accordingly to avoid it quickly dirtying lots … <\/p>\n
Continue reading “fs: Make write(2) interruptible by a fatal signal”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[83],"tags":[762,1711],"_links":{"self":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts\/6361"}],"collection":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/comments?post=6361"}],"version-history":[{"count":0,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts\/6361\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/media?parent=6361"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/categories?post=6361"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/tags?post=6361"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}