On Sun, Sep 10, 2006 at 06:35:00PM +0100, Nix wrote: > I must admit I can't see what's so special about the root filesystem. The tools you are running may be stored on it and access files on it. Some operations the tools do temporarily suspend I/O to the LVs involved. If a tool suspends I/O to the root then does anything that causes an access to it the system can lock up. Caches/flushing/scheduling can make this indeterminate. Even the filesystem type matters (e.g. timing of journal transactions e.g. lazy inode time updates). > The tools work for me: even doing things like pvmoving root filesystems in > active use works fine. I'd vaguely guess that only snapshot support is > broken? pvmove also may fail. Workaround is to copy required components into ramdisk and run from there. I have never done a complete audit, but: lvm binary (& libraries) should not be on root filesystem [use lvm.static in ramdisk] /dev must not be part of root filesystem being changed [ramdisk copy] log/activation = 0 in lvm.conf (the default) Depending on the particular command and configuration there may be more restrictions. (E.g. some commands may still require config files and lock files not to be in the root filesystem.) dmeventd is also unsafe as currently implemented - one reason it is not enabled by default upstream. Upstream support entails a full review and changes to deal with as many problems as possible (regardless of the user's configuration and compile-time options) and then detecting the remaining problems and issuing warning messages or refusing to proceed as appropriate. Alasdair -- agk@redhat.com _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
