Re: [RFC] [PATCH] VM & VFS changes

From: Andre Guibert de Bruet <andy_at_siliconlandmark.com>
Date: Wed, 1 Jun 2005 21:26:50 -0400 (EDT)
On Wed, 1 Jun 2005, Don Lewis wrote:
> On  1 Jun, Andre Guibert de Bruet wrote:
>> On Wed, 1 Jun 2005, Alexander Leidinger wrote:
>>> Poul-Henning Kamp <phk_at_phk.freebsd.dk> wrote:
>>>
>>>> Maybe the simplest solution is also the best:  keep track of the
>>>> dependencies and do the cleanup leaf->root on the resulting tree.
>
> It might not even be necessary to use a tree.  It might be possible to
> just use a list like vfs_unmountall().

I do some similar magic in my diff, to check for devfs. I can write a 
function that unmounts all mds first.

>>> How many userland processes have to be running and consuming memory which
>>> isn't available as physical RAM at this point in the shutdown sequence?
>>>
>>> Wouldn't a loop like the following be enough?
>>> while swap
>>>     umount unbusy-FS
>>>     swap-off swap
>>>
>>> This assumes that swap-off doesn't turns off the swap if it isn't able to put
>>> everything back into other swap or physical RAM areas.
>>
>> I would think that one would want to disable swapping before the unmount
>> of filesystems for the very fact you could have vnode-backed swapspace in
>> use.
>
> This order doesn't work either because you might only have 128 MB of
> RAM, but 1 GB of data in /tmp, which is stored on a swap-backed memory
> disk.  In this case you'll have to unmount /tmp and toss the md contents
> before you disable swap.

I could modify my patchset to get a first pass at MDs, then disable swap, 
then unmount UFS/FFS/ext2/etc, then devfs. The question becomes: Is this 
the correct process that we should follow? It makes sense to me. I would 
like to get input from our VM & VFS gurus on this before I schedule a 
hack-and-testathon... :-)

Cheers!
Andy

/*  Andre Guibert de Bruet  * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/*   Code poet / Sysadmin   * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/*   GSM: +1 734 846 8758   * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com *      Tormenting bytes since 1980.       */
Received on Wed Jun 01 2005 - 23:26:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:35 UTC