Date: Sat, 03 Feb 2007 13:35:01 +0100 From: Ivan Voras <ivoras@fer.hr> To: Pieter de Goeje <pieter@degoeje.nl> Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: First steps towards importing gvirstor into -current Message-ID: <45C48175.5060704@fer.hr> In-Reply-To: <200702031238.52771.pieter@degoeje.nl> References: <epspv7$a9e$1@sea.gmane.org> <45C336D7.2060109@fer.hr> <20070202133055.GB21290@garage.freebsd.pl> <200702031238.52771.pieter@degoeje.nl>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Pieter de Goeje wrote: > GEOM_VIRSTOR[1]: All physical space allocated for test > GEOM_VIRSTOR[5]: Failed to allocate physical chunk for virstor/test > g_vfs_done():virstor/test[WRITE(offset=103153664, length=131072)]error = 28 > It spitted out these messages in a tight loop (100% sys load). I was unable to Yes, it turns out the file system gets confused if the device reports a certain size and then returns ENOSPC (error 28) when it shouldn't. Unfortunately, yanking the device from under the file system would panic the kernel. Returning EIO could either panic it or "just" end up with a corrupted file system. Any ideas from the more VFS-savvy? The "tight loop" seems to be VFS retrying, inserting the requests to GEOM layer over and over... > Also, no warning was issued when it aproached 0% free physical space. > I would expect the system to simply abort the write operation (possibly > needing a background fsck after adding another component to make more space). It should - are you sure the message didn't get lost/overflown in the log? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFxIF1ldnAQVacBcgRAkBWAJ4ya8upiFMd5Np+y5l6Gk6YSp9HkQCeI0qT 4JO8juuu/dfD5WTjEEJsGNg= =7B2D -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45C48175.5060704>