On Thu, 6 Oct 2011 20:11:51 -0600, MJ (Michal) wrote: > On Thu, Oct 06, 2011 at 05:05:06PM -0600, Eric Blake wrote: > > On 10/06/2011 05:01 PM, Michael Schwendt wrote: > > >>> you would not notice any troubles. > > >> > > >> Umm, yes you would. That's not atomic, and risks leaving things in an > > >> inconsistent state. > > >> > > >> http://www.flamingspork.com/talks/2007/06/eat_my_data.odp > > >> http://www.pixelbeat.org/docs/unix_file_replacement.html > > > > > > cp -f ${grub_cfg}.new ${grub_cfg} ; rm -f ${grub_cfg}.new > > > > > > Better? > > > > No. cp is not atomic. > > I think that in this particular case you are overdoing that concern. > These are small files and real writes are in blocks and not > characters. Well, to defend Eric, it's okay to be pedantic in this case at a technical level. Sort of. Late at night I just couldn't believe that fearing power-loss at the end of a grub2-mkconfig run would be a major concern or the only concern. That's after I had run into a major pitfall with that damn symlink and ended up with two config files and therefore an inconsistency. Especially since I cannot tell whether any other properties are to be guaranteed as well for the entire grub.cfg update process. Rather than a power outage, bad config file changes have hit me before, fwiw, both when not noticing a poor mistake I made myself or with automatically updated files. With features like os-proper and template processing, the completely regenerated config file has become more complex and bears enough potential for something to break. When fearing ill-timed power-loss, the admin would rather not use the -o output file option, but first create and review a new grub.cfg in a separate file and then move it to the right place. grubby also rename(2)s its grub.conf file in the final step, btw, but that hasn't been the only place where to prevent failure. Enough users with GRUB 1 have encountered reboot breakage after applying kernel updates. Assumedly due to flaws elsewhere. GRUB 2 is being advertised as "rewritten from scratch" as well as | cleaner, safer, more robust, more powerful, and more portable. so one wouldn't want to replace the final "mv" with something that would become an Achilles’ heel. ;) -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc8.git0.1.fc16.x86_64 loadavg: 0.09 0.26 0.20 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
