Jacob Burkamper: > The git log shows the hash 446c276507d9791be4612b30745d7789b266d87b as the > last commit before this version.
Ok, it is 446c276 2014-07-07 UBUNTU: Ubuntu-3.13.0-32.56 Here are the reasons why remount,ro for ext2 fails. - security_sb_mount() and security_sb_remount() your LSM rejects. - sb->s_writers.frozen != SB_UNFROZEN and mnt_get_writers(mnt) someone is writing to the fs now, inclusding suspend/resume. if aufs forgets calling sb_end_write() somewhere, then this problem will happen. but, other phenomenona should happen in various places in this case. so the possibility of this case is not high I suppose. - atomic_long_read(&sb->s_remove_count) inode is already dead but not discarded yet. usually all dead inodes on that fs are discarded at remount-time. here "dead" means the link count is zero. for example, if a process opens a file and then unlink it, then the file's link count becomes zero but the file is still in-use. in this case, the fs keeps busy until the process terminates or closes the file. For now, we should focus why remount readonly failed and what makes the fs busy. If many fsck take long time, it may be possible to replace them by "remount,ro" + "remount,rw". J. R. Okajima ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
