Announcing: gvirstor
Ivan Voras
(currently) named "gvirstor". The purpose of this class is to enable
creation of huge virtual providers (for example: many terabytes) backed
by limited physical storage, with the expectation that more physical
storage will be added later. This is a part of a logical volume manager,
and provides functionality up to now not available as a native GEOM
class.
gvirstor is currently available either from Perforce (under the name
\\gvirstor) or at http://wiki.freebsd.org/gvirstor in a convenient tbz
archive with appropriate Makefile. Please read the README file packaged
in the archive for instructions on how to build and run gvirstor.
Here are some usage examples from the man page:
The following example shows how to create a virtual device of default
size (2 TiB), of default chunk (extent) size (4 MiB), with two physical
devices for backing storage.
gvirstor label -v mydata /dev/ad4 /dev/ad6
newfs /dev/virstor/mydata
From now on, the virtual device will be available via the
/dev/virstor/mydata device entry. To add a new physical device /
provider to an active virstor device:
gvirstor add mydata ad8
This will add physical storage (from ad8) to /dev/virstor/mydata device.
To see device status information (including how much physical storage is
still available for the virtual device), use:
gvirstor list
The latest version of gvirstor is called "beta3" because it has not
received much testing, especially on non-i386 architectures. Please help
by testing both stability and performance of gvirstor if you have
equipment and time.
This work was sponsored by Google with its "Summer of Code 2006"
project, the (very helpful :) ) mentor was Pawel Jakub Dawidek (pjd).
Yoshihiro Ota
I gave a shot at this but it didn't work.
I downloaded gvirstor-beta3.tbz.
I have a coupe of questions.
1. Is this -current only?
I tried on 6.1 and 6-stable(currently 6.2-RERELEASE)
2. Have you made any changes since you posted the orginal e-mail?
3. If so, how do you check out fro "Perforce (under the name \\gvirstor)"?
Here is some output I got afer # make ; make so
Thanks,
Hiro
# make install
install -o root -g wheel -m 555 geom_virstor.ko /boot/kernel
kldxref /boot/kernel
# ./gvirstor label -v -s 500 test md2 md3
Unknown command: label
usage: gvirstor help
gvirstor list [name ...]
gvirstor status [-s] [name ...]
gvirstor load [-v]
gvirstor unload [-v]`
# grep label *c
g_virstor.c:/* Declare malloc(9) label */
geom_virstor.c: {"label", G_FLAG_VERBOSE | G_FLAG_LOADKLD, virstor_main,
geom_virstor.c:static void virstor_label(struct gctl_req *req);
geom_virstor.c: if (strcmp(name, "label") == 0)
geom_virstor.c: virstor_label(req);
geom_virstor.c:virstor_label(struct gctl_req *req)
On Fri, 25 Aug 2006 17:10:46 +0200
Ivan Voras <ivo...@fer.hr> wrote:
> I'm glad to announce availability of GEOM virtual storage class,
> (currently) named "gvirstor". The purpose of this class is to enable
> creation of huge virtual providers (for example: many terabytes) backed
> by limited physical storage, with the expectation that more physical
> storage will be added later. This is a part of a logical volume manager,
> and provides functionality up to now not available as a native GEOM
> class.
>
> gvirstor is currently available either from Perforce (under the name
> \\gvirstor) or at http://wiki.freebsd.org/gvirstor in a convenient tbz
> archive with appropriate Makefile. Please read the README file packaged
> in the archive for instructions on how to build and run gvirstor.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Ivan Voras
> 1. Is this -current only?
> I tried on 6.1 and 6-stable(currently 6.2-RERELEASE)
No, it's for RELENG_6. I'm interested in people testing it before it's
committed to -current!
> 2. Have you made any changes since you posted the orginal e-mail?
Not significantly.
> Here is some output I got afer # make ; make so
> install -o root -g wheel -m 555 geom_virstor.ko /boot/kernel
> kldxref /boot/kernel
You may need to 'kldload geom_virstor'.
> # ./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
Also, take care to remove CFLAGS line from Makefile if you don't have a
kernel with INVARIANTS and WITNESS.
I hope to hear about your experience with it.
Yoshihiro Ota
Ivan Voras <ivo...@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
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Ivan Voras
> 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.
If it's a much requested feature, I'll implement it; as it is currently
done, only unused components at the end of the list of components can be
removed.
> 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
Ok, I'll try this situation at my development machine.
> # ./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.
Kernel panic message may tell you what system panicked.
> I will try as time permitts.
Thank you.
Ivan Voras
> 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.
To revisit this thread - I tried steps similar to those above (using
real devices instead of md) and can't reproduce the panic.