On Mon, 29 Nov 2010, Jonathan Nieder wrote: > Guillem Jover wrote: > > Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) > > instead, skimming over the kernel source seems to indicate it might > > end up doing more or less the same thing but in a portable way? > > Probably a silly question, but what does "The specified data will not > be accessed in the near future" have to do with preventing delayed > allocation?
It means we don't need to keep it in RAM since we're not going to read/modifiy it again in the near future. Thus the writeback can be started right now since delaying it will not save us anything. At least that's the way I understand the situation. > Put another way: if this works now, is it likely to continue to work? Well, it will always work (the code is unlikely to introduce failures), but the resulting behaviour is entirely up to the kernel to decide. So there's no guaranty that the optimization will last. On the other hand, the whole point of posix_fadvise() is to give hints to the kernel so that he can decide on the best course of action. So I hope the interpretation above is one the main motivation behind that hint. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
