Re: g_vfs write error = 28, bad memory?
On Sun, 2 Sep 2007, Kris Kennaway wrote:
Ian Smith wrote:
On Sat, 01 Sep 2007 19:34:41 +0200 Kris Kennaway [EMAIL PROTECTED] wrote:
Per olof Ljungmark wrote:
[..]
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).
Ah. Swap backing with no swap configured sounded oxymoronic, and I was
confused and left guessing by md(4) on 5.5-STABLE (March) till checking:
http://www.freebsd.org/cgi/man.cgi?query=mdapropos=0sektion=0manpath=FreeBSD+7-currentformat=html
which explains swap backed operation in one short but crucial sentence.
But is running out of memory with swap-backed md (with no swap) likely
to be any prettier than the panics from (unreserved) malloc backing?
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.
By 'ideally' I guess you mean that it doesn't, yet? I hope to get a
Soekris 4801 before too long, which will provide a chance to experiment
(though I'll likely run it from one of my old 4GB laptop drives anyway).
Also noted in passing: the 'auto' parameter to bsdlabel(8) used by one
mdconfig(8) example is undocumented, though supported in bsdlabel.c
Thanks,
Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
Ian Smith wrote:
On Sun, 2 Sep 2007, Kris Kennaway wrote:
Ian Smith wrote:
On Sat, 01 Sep 2007 19:34:41 +0200 Kris Kennaway [EMAIL PROTECTED] wrote:
Per olof Ljungmark wrote:
[..]
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).
Ah. Swap backing with no swap configured sounded oxymoronic, and I was
confused and left guessing by md(4) on 5.5-STABLE (March) till checking:
http://www.freebsd.org/cgi/man.cgi?query=mdapropos=0sektion=0manpath=FreeBSD+7-currentformat=html
which explains swap backed operation in one short but crucial sentence.
But is running out of memory with swap-backed md (with no swap) likely
to be any prettier than the panics from (unreserved) malloc backing?
Probably not. No worse though.
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.
By 'ideally' I guess you mean that it doesn't, yet? I hope to get a
Soekris 4801 before too long, which will provide a chance to experiment
(though I'll likely run it from one of my old 4GB laptop drives anyway).
Correct.
Also noted in passing: the 'auto' parameter to bsdlabel(8) used by one
mdconfig(8) example is undocumented, though supported in bsdlabel.c
OK, you should submit a PR.
Kris
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
On Mon, 3 Sep 2007, Kris Kennaway wrote: Ian Smith wrote: [..] But is running out of memory with swap-backed md (with no swap) likely to be any prettier than the panics from (unreserved) malloc backing? Probably not. No worse though. Couldn't be :) By 'ideally' I guess you mean that it doesn't, yet? I hope to get a Correct. Ta. Had a bit of a browse through md.c, but soon got a stiff neck. Also noted in passing: the 'auto' parameter to bsdlabel(8) used by one mdconfig(8) example is undocumented, though supported in bsdlabel.c OK, you should submit a PR. FWIW, docs/116047 Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
Ian Smith wrote:
On Sat, 01 Sep 2007 19:34:41 +0200 Kris Kennaway [EMAIL PROTECTED] 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
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
g_vfs write error = 28, bad memory?
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, Per olof ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
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...] or memory disk image truncated... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
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. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
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. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
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...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
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.
Kris
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs write error = 28, bad memory?
On Sat, 01 Sep 2007 19:34:41 +0200 Kris Kennaway [EMAIL PROTECTED] 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 ..
Cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
