[RFC] [PATCH] VM & VFS changes
Scott Long
scottl at samsco.org
Thu Jun 2 01:48:24 GMT 2005
Andre Guibert de Bruet wrote:
>
> 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
>
This order sounds reasonable. I don't have much more to add, your
discussion so far seems to be going in the right direction.
Scott
More information about the freebsd-current
mailing list