g_vfs write error = 28, bad memory?

[Kris Kennaway]

Ian Smith wrote:
> On Sat, 01 Sep 2007 19:34:41 +0200 Kris Kennaway <kris at FreeBSD.org> wrote:
>  > Per olof Ljungmark wrote:
>  > > Kris Kennaway wrote:
>  > >> Per olof Ljungmark wrote:
>  > >>> Kris Kennaway wrote:
>  > >>>> Per olof Ljungmark wrote:
>  > >>>>> I use a memory file system for some tmp files and last night I saw 
>  > >>>>> this, followed by a reboot. Bad memory? 6-STABLE from April..
>  > >>>>>
>  > >>>>> foo-bar kernel: g_vfs_done():md0[WRITE(offset=259244032, 
>  > >>>>> length=131072)]error = 28
>  > >>>>> foo-bar kernel: g_vfs_done():md0[WRITE(offset=259375104, 
>  > >>>>> length=131072)]error = 28
>  > >>>>> [ten more lines...]
>  > >>>>> [reboot]
>  > >>>>>
>  > >>>>> Thanks,
>  > >>>>
>  > >>>> #define ENOSPC          28              /* No space left on device */
>  > >>>>
>  > >>>> You are probably (incorrectly) using a malloc backed disk.  Use swap 
>  > >>>> backing and you won't panic when memory is low.
>  > >>>
>  > >>> Yes, sounds likely, thanks. One more question then, where is the md 
>  > >>> information stored through a reboot? I did not edit rc.conf or fstab 
>  > >>> or kernel config but still /dev/md0 came back up. Hmmm.
>  > >>
>  > >> It's not, unless something is explicitly creating it each time you 
>  > >> boot.  Perhaps you are using a rc.conf setting that creates a md /tmp.
>  > > 
>  > > Indeed, here it was:
>  > > 
>  > > amavisd_enable="YES"
>  > > amavisd_ram="512m"
>  > > 
>  > > and the line in rc.d/amavisd
>  > > mdmfs -M -s ${amavisd_ram} -w vscan:vscan md /var/amavis/tmp || true
>  > > for some reason creates a malloc based mfs
>  > > 
>  > > Perhaps I should check this with the maintainer...
>  > > 
>  > > 
>  > 
>  > Yes, malloc backing for md should be used in almost no situations.
> 
> Am I right in thinking such situations would then be limited to diskless
> / flashdisk / embedded systems having no swap?  Seems obvious, but ..

Sort of.  Swap backing will still work when you have no swap, and it's 
still faster than malloc backing.  The problem is that I think backing 
store reservation ("-o reserve") doesn't work unless you have actual 
swap to back everything, whereas with malloc backing it reserves in 
memory.  This means that it is easy to overcommit memory and the system 
will probably panic when it suddenly finds no free memory for the md (as 
in the original email).

Ideally if no swap was configured, swap backing would also reserve the 
space in memory, and then I am not aware of any other reasons to 
continue using malloc backing.

Kris