login
Search
Pawel Jakub Dawidek announced that GEOM Gate [story] is ready for testing, though internal documentation still notes, "This is highly experimental software and isn't finished yet. Keep that in mind." GEOM Gate is built upon the GEOM 'stackable BIO subsystem' [story], and allows for the remote mounting of disk devices across a network. From the documentation:
"For example you have two machines: 'client' and 'server' and you want to mount /dev/ad0s1a from the 'server' machine on the 'client' machine."
The current GEOM Gate implementation uses the TCP protocol to transport data. Pawel notes that for better performance it should also be implemented to use UDP. Pawel's full email follows, and includes links to much more information describing the new functionality.
From: Pawel Jakub Dawidek [email blocked] To: freebsd-hackers Subject: GEOM Gate. Date: Tue, 14 Oct 2003 14:47:47 +0200 Hello hackers... Ok, GEOM Gate is ready for testing. For those who don't know what it is, they can read README: http://garage.freebsd.pl/geom_gate.README and presentation from WIP/BSDCon03 session: http://garage.freebsd.pl/GEOM_Gate.pdf After compliation (cd geom_gate; make; make install) you should run regression tests: # regression/runtests.sh If everything will went ok you can play with GEOM Gate and report any bugs. I've spend some time to made GEOM Gate force-remove-safe so using '-f' option with ggc(8) should be always safe. Ah! Four manual pages are added, so feel free to read them first (gg(4), geom_gate(4), ggc(8), ggd(8)) http://garage.freebsd.pl/geom_gate.tbz Enjoy! -- Pawel Jakub Dawidek [email blocked] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net
UDP? Ehm?
UDP in that environment?
...
Is he stupid?
I don't think so. Unless you
I don't think so. Unless you have been writing something similar for the past 8 years, and have way better understanding than he does?
I'm pretty confidant that -being a senior kernel hacker- he knows UDP doesn't guarantee delivery, natively. So I'm sure he has something more elaborate worked out in his mind.
What it is, I don't know. I am still trying to understand GEOM as it is. :)
Anonymous coward
What a comment made to someone who gives us great functions in bsd.
Have you even been to the garage?
Obviously not, and it seems a lot here have no idea whatsoever what GEOM is. Read the man page, it might help you to understand what this is, and when you call something stupid, step back and also call Sun, IBM, the same name.
In the end, when things hit 5.0 you'll be amazed.
Open your mouth, and swallow yer foot up to the knee
Difference ?
I am missing something. How's different than NFS protocol ? Granted it uses TCP/IP, it guarantees the delivery of packages but still if network goes down, the files will be left in an indeterminate state. Care to explain more ....
Re: Difference ?
The NFS protocol is done at the filesystem level. This is done at block device level. This would give it more flexibility, but it would have less opportunity for optimisations. If the network goes down, I guess it has similar sorts of failure modes as NFS, although they would be potentially more damaging that NFS failures.
cute ...
... but don't use in a production environment unless you want to feel sorry for yourself. I'll stick with NFS. Would be better if he used his formidible talent on a more worthy project.
Ahem...
There is nothing inherently wrong with using UDP for data, you just have to do much of the stuff that TCP does "for you" by hand instead (such as checking for packet loss).
Many people mention NFS in the comments...well, NFS uses UDP by default, it can use TCP as well (since kernel version 2.2.19 if I'm not mistaken), but UDP has been the default protocol from the beginning, TCP is an add-on.
Give the guy some credit here...
Linux's NBD
How is this different than Linux's Network Block Device:
http://www.xss.co.at/linux/NBD/
or is that what it is - a clone of NBD?
Yea, this is the same thing a
Yea, this is the same thing as NBD for linux, but,
since it's done inside the GEOM framework of FreeBSD,
better!
It's not neccessarily a clone, IMHO, as it's a pretty
concept and I doubt the protocols the same.
Doooh! I meant to say "prett
Doooh! I meant to say "pretty simple concept"
Once again...
...this is great, but when can it become an iSCSI implementation? Or rather, can it ever become or lead to an iSCSI implementation?
I can think of some niche uses for this - imaging drives... sharing removable media drives (hm, does GEOM do opticals - CD-R, DVD-R, Mt. Rainier drives? ... if not, MO or Zip, perhaps) over a network... but then, that itself is what iSCSI is for, ain't it?
I'm not out to rain on anyone's parade, it's certainly an awesome hack, iSCSI is certainly relatively big and crufty and would require translation to/from GEOM (at least, if you want IDE devices to have equal opportunity) to implement... but I'm straining to see a use for this outside of homogenous BSD environments. Meanwhile, everyone's excited about the stuff it can do, but none of the fans seem to even acknowledge iSCSI's existence.
So what's the deal? Is iSCSI patent-encumbered or something? Does it just look like a NIH problem because we're still celebrating GEOM working at all? Is there an actual technical/NIH problem (performance blows away iSCSI, there're other technical reasons to want the world to adopt GEOM as a new block-level abstraction?)? Should this just be taken as a cool "because it's there" hack, and I'm the only one stressing over the "usefulness?"
I just feel like I'm missing some backstory here. groups.google.com turns up only a single hit for
geom gate iscsi, and sadly, I'm not fluent in Polski. ;)