Hi Don, hi all, > I just thought of a case where this might not work. It is possible to > create a swap-backed md, use it to back a file system, add a bunch of > swap, and then fill the file system, consuming the swap space. if you > do the cleanup processing in reverse order, the first operation would be > to remove the swap device, which you might not be able to do because of > a lack of RAM and alternate swap space. I am maybe missing something, but at time of shutdown when filesystems are going to be unmounted, I think user processes don't exist any longer. Do kernel threads consume so much memory sometimes that they won't fit in RAM ? > [...] > Taking care of the md's first is a good idea for the sake of efficiency, > because it eliminates the need to page in any of their contents that > have been paged out to swap. The problem is that if they are used to > back file systems, any dependent file systems must be unmounted first, > and that might not be possible if one of the dependent file systems > contains a swap file. An example would be using an md to back /tmp, > mounting /dev/adXXX on /tmp/foo, and adding /tmp/foo/swapfile as a swap > device. It might not be possible to clean up this arrangement at > shutdown without deadlocking. > > If a dependency tree is maintained, it should be possible prevent the > troublesome cases from happening. If swapping to a swap-backed md or > swapping to vnode-backed md that resides in a file system that is > dependent on a file system that resides on a swap-backed md are > forbidden, I think that is sufficient to prevent deadlock. Does the suppression a warning at shutdown (devfs) really needs to lead to a feature diminution ? This might appear overkill. Although such setups you describe seems to be slightly useless, we can imagine that, in the future, resources restrictions may be applied to jails and this would allow to set a vnode-backed swap partition for each jail. I'm not sure at all if this is going to happen someday, but I just wanted to point out that removing a feature now for this purpose could be a problem in the future/ Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >Received on Thu Jun 02 2005 - 08:46:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:35 UTC