Block device over network from Linux to FreeBSD

All right, here's a question that'll make your IQ drop by 5
points
just from pondering it 

What's the best way to provide, over the network, a block
device on
harddrives that live on a Linux box and "export"
them to a FreeBSD
machine? Aka I want a FreeBSD filesystem on harddrives that
are
physically in a Linux box.

Long story:

My backup strategy is a FreeBSD filesystem with snapshots on
a bunch
of harddrives that live on networked computers in the
basement.  All
these computers boot diskless or disky into a variety of
OSes, usually
Linux or FreeBSD.  It would be easy to just use ext2fs or
another
filesystem supported by both, but I'd really like ufs2
snapshots.  So
I need to access the disks in a box running Linux as a block
device
from a machine running FreeBSD.  When the machine having the
physical
disks runs FreeBSD I want to access the same raw devices
directly, of
course.

The brute-force approach would be:
- ext2fs on disks
- files inside ext2fs for use via mdconfig (and ccd)
- then, depending on OSes booted, either:
  - export via NFS and mdconfig on NFS mounts on remote
FreeBSD machine
  - direct FreeBSD mount (machine runs FreeBSD)

Another alternative I see is VMware or if any of the free
emulators
can boot FreeBSD on Linux and use the disks directly in the
guest OS.

Linux has a network layer for block devices:
http://www.it.uc3m.es/
ptb/nbd/ . On first sight, it doesn't look too
exiting nor does it look straightforward to implement a
client in
GEOM.  It uses daemons on both ends, so failover will not
exactly be
an improvement over NFS.  At least with NFS you know that a
lot of
other people depend on what you write being delivered
eventually.

Then there's ATA over Ethernet as an established protocol.

Any other ideas?

USB'ing the harddrives is not considered sportish 

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%
Martin Cracauer <cracauercons.org>   http://www.cons.org/cra
cauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

Martin Cracauer wrote:
> All right, here's a question that'll make your IQ drop
by 5 points
> just from pondering it 
> 
> What's the best way to provide, over the network, a
block device on
> harddrives that live on a Linux box and
"export" them to a FreeBSD
> machine? Aka I want a FreeBSD filesystem on harddrives
that are
> physically in a Linux box.
> 
> Long story:
> 
> My backup strategy is a FreeBSD filesystem with
snapshots on a bunch
> of harddrives that live on networked computers in the
basement.  All
> these computers boot diskless or disky into a variety
of OSes, usually
> Linux or FreeBSD.  It would be easy to just use ext2fs
or another
> filesystem supported by both, but I'd really like ufs2
snapshots.  So
> I need to access the disks in a box running Linux as a
block device
> from a machine running FreeBSD.  When the machine
having the physical
> disks runs FreeBSD I want to access the same raw
devices directly, of
> course.
> 
> The brute-force approach would be:
> - ext2fs on disks
> - files inside ext2fs for use via mdconfig (and ccd)
> - then, depending on OSes booted, either:
>   - export via NFS and mdconfig on NFS mounts on remote
FreeBSD machine
>   - direct FreeBSD mount (machine runs FreeBSD)
> 
> Another alternative I see is VMware or if any of the
free emulators
> can boot FreeBSD on Linux and use the disks directly in
the guest OS.
> 
> Linux has a network layer for block devices:
> http://www.it.uc3m.es/
ptb/nbd/ . On first sight, it doesn't look too
> exiting nor does it look straightforward to implement a
client in
> GEOM.  It uses daemons on both ends, so failover will
not exactly be
> an improvement over NFS.  At least with NFS you know
that a lot of
> other people depend on what you write being delivered
eventually.
> 
> Then there's ATA over Ethernet as an established
protocol.
> 
> Any other ideas?
> 
> USB'ing the harddrives is not considered sportish 
> 
> Martin


iSCSI?


Eric




_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

Martin Cracauer wrote:
> All right, here's a question that'll make your IQ drop
by 5 points
> just from pondering it 

> Any other ideas?

If you're into programming, you can port the ggatec daemon
that serves
as an end-point for ggated. Ggatec is userland-only and it
just does IO
to/from a local file or device, nothing fancy (something
like completely
nonstandard variant of iSCSI, ATA over ethernet, etc.).

On Fri, Aug 17, 2007 at 08:50:26PM +0200, Ivan Voras wrote:
> Martin Cracauer wrote:
> > All right, here's a question that'll make your IQ
drop by 5 points
> > just from pondering it 
> 
> > Any other ideas?
> 
> If you're into programming, you can port the ggatec
daemon that serves
> as an end-point for ggated. Ggatec is userland-only and
it just does IO
> to/from a local file or device, nothing fancy
(something like completely
> nonstandard variant of iSCSI, ATA over ethernet,
etc.).

Right, but you confused ggatec with ggated. ggated is
userland only
daemon and is the one which should be ported.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjdFreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I
Am!

Pawel Jakub Dawidek wrote:
> On Fri, Aug 17, 2007 at 08:50:26PM +0200, Ivan Voras
wrote:
>> Martin Cracauer wrote:
>>> All right, here's a question that'll make your
IQ drop by 5 points
>>> just from pondering it 
>>> Any other ideas?
>> If you're into programming, you can port the ggatec
daemon that serves
>> as an end-point for ggated. Ggatec is userland-only
and it just does IO
>> to/from a local file or device, nothing fancy
(something like completely
>> nonstandard variant of iSCSI, ATA over ethernet,
etc.).
> 
> Right, but you confused ggatec with ggated. ggated is
userland only
> daemon and is the one which should be ported.

Yes, you're right, thanks!

Everything above is correct, just reverse ggatec and ggated
(c=client/consumer=the part that manages the kernel device,
d=daemon/provider=the part that provides the data for the
device).