Date: Tue, 26 Sep 2006 22:15:47 -0500 From: Yoshihiro Ota <ota@j.email.ne.jp> To: Ivan Voras <ivoras@fer.hr> Cc: geom@freebsd.org, current@freebsd.org Subject: Re: Announcing: gvirstor Message-ID: <20060926221547.1ae6f72a.ota@j.email.ne.jp> In-Reply-To: <4518DE53.9070101@fer.hr> References: <44EF12F6.3000806@fer.hr> <20060925213522.4c9eacb7.ota@j.email.ne.jp> <4518DE53.9070101@fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Sep 2006 10:01:23 +0200
Ivan Voras <ivoras@fer.hr> wrote:
> Ota wrote:
>
>
> > # ./gvirstor label -v -s 500 test md2 md3
> > Unknown command: label
>
> This means the .so file has not been found.
>
> I see now what's going on: I've forgot to add a step to the README: make
> a symlink of geom_virstor.so in your /lib/geom directory:
>
> /lib/geom# ln -s /path_to_gvirstor/geom_virstor.so
Indeed, this was the problem, and now:
# ./gvirstor label -v -s 5000 test md2 /dev/md3
Resizing virtual size to fit virstor structures
New virtual size: 5120 MB (30 new chunks)
Total virtual chunks: 1280 (4 MB each), 5120 MB total virtual size.
Clearing metadata on md2 /dev/md3.
Writing allocation table to md2... (0 MB, 1 chunks)
Storing metadata on md2 (250 chunks) /dev/md3 (250 chunks) Done.
# newfs -U /dev/virstor/test
/dev/virstor/test: 5120.0MB (10485760 sectors) block size 16384, fragment size 2048
using 28 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
with soft updates
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976,
3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792,
6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608,
9408960, 9785312, 10161664
> Also, take care to remove CFLAGS line from Makefile if you don't have a
> kernel with INVARIANTS and WITNESS.
"-g" option was required in "CFLAGS"; otherwise, kldload failed.
> I hope to hear about your experience with it.
Reading "gvirstor implementation details", it is not intended to remove components, is it? If not, it will a grate benefit to allow "take-off" components as some device may go bad while other devices are still functioning when a virstor is created with multiple devices.
I tried it anyway. It seemed that I was able to detach md3 and then add md4. Md3 was not used at all when I removed; status only displaed md2 but I was not sure if it was removed perfectly in gvirstor as no mention in the document. Later, I was not able to add md3 back again.
These are the command lines I tried
# mount /dev/virstor/test /mnt/tmp
# tar xf ports.tar.bz -C /mnt/tmp &
# ./gvirstor remove test md3
# ./gvirstor add test md4
# ./gvirstor status test
# ./gvirstor add test md3
Kernel paniced after a while. Many things were going so it was not sure that gvirstor was the cause of the problem.
I will try as time permitts.
Thanks,
Hiro
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060926221547.1ae6f72a.ota>