Server simulating a usb disk

Hi all,
is it possible in Linux, using a USB-to-USB cable, to have one of the
two computers (A, the server) provide data to the other one (B)
appearing to B as if there was a USB key connected?

Something like sharing a directory but appearing to the outside like an
USB-key

TIA

["Followup-To:" header set to alt.os.linux.]
linuxnewbie1234 enlightened us with:
> is it possible in Linux, using a USB-to-USB cable, to have one of
> the two computers (A, the server) provide data to the other one (B)
> appearing to B as if there was a USB key connected?

Yes it is, using the "gadget" class modules. I think you want the
g_file_storage module.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

On Mon, 14 Aug 2006 13:25:27 +0200, linuxnewbie1234 rearranged some
electrons to form:

> Hi all,
> is it possible in Linux, using a USB-to-USB cable, to have one of the
> two computers (A, the server) provide data to the other one (B)
> appearing to B as if there was a USB key connected?
>
> Something like sharing a directory but appearing to the outside like an
> USB-key
>
> TIA

Why not use the ethernet port and NFS?

--
David M (dmacchiarolo)
http://home.triad.rr.com/redsled
T/S 53
sled351 Linux 2.4.18-14 has been up 19 days 23:05

David M напиÑ?ав:
> On Mon, 14 Aug 2006 13:25:27 +0200, linuxnewbie1234 rearranged some
> electrons to form:
>
> > Hi all,
> > is it possible in Linux, using a USB-to-USB cable, to have one of the
> > two computers (A, the server) provide data to the other one (B)
> > appearing to B as if there was a USB key connected?
> >
> > Something like sharing a directory but appearing to the outside like an
> > USB-key
> >
> > TIA
>
> Why not use the ethernet port and NFS?
>
> --
> David M (dmacchiarolo)
> http://home.triad.rr.com/redsled
> T/S 53
> sled351 Linux 2.4.18-14 has been up 19 days 23:05

IMHO com-port and ftp or smb be a better

On 2006-08-15, David M <(E-Mail Removed)> wrote:
> Why not use the ethernet port and NFS?

'cause you cannot boot from NFS without a floppy, a CD or something else,
but you can from USB (most of the time).

Davide

--
Linus was the instructor of Hercules in music, but having one day reproved
his pupil rather harshly, he roused the anger of Hercules, who struck him
with his lyre and killed him.

Sybren Stuvel wrote:

> ["Followup-To:" header set to alt.os.linux.]
> linuxnewbie1234 enlightened us with:
>> is it possible in Linux, using a USB-to-USB cable, to have one of
>> the two computers (A, the server) provide data to the other one (B)
>> appearing to B as if there was a USB key connected?
>
> Yes it is, using the "gadget" class modules. I think you want the
> g_file_storage module.

What cable(s) does it work with? I have a DVD/DivX player with USB storage
interface, and it would be awesome if i could mount a loopback filesystem
from my server.

--
Lasse Jensen [fafler at g mail dot com]
Linux, the choice of a GNU generation.

L0n3R4ng3r wrote:
> David M напиÑ?ав:
>> Why not use the ethernet port and NFS?
> IMHO com-port and ftp or smb be a better


Unfortunately for my specific task I really need USB, but anyways this
is an interesting topic (for another task) so I will ask here:

1. Do you think that NFS, FTP or SMB are faster than USB2.0?

2. Do you think that an NFS, FTP or SMB share is more stable than
USB2.0? We have an NFS share among 2 computers with a direct connection
(LAN crossed cable): I must say I am not impressed. Not only it seems to
be way slower than a native USB disk but also has serious problems in
listing directories with thousands of names: it hangs up.

3. Which one is the fastest and most stable among NFS, FTP and SMB, for
an use in a totally trusted environment (such as a LAN crossed cable)?

Thanks for your time

linuxnewbie1234 <(E-Mail Removed)> writes:

> 1. Do you think that NFS, FTP or SMB are faster than USB2.0?

On a gigabit network or better, yes.

> 2. Do you think that an NFS, FTP or SMB share is more stable than
> USB2.0? We have an NFS share among 2 computers with a direct
> connection (LAN crossed cable): I must say I am not impressed. Not
> only it seems to be way slower than a native USB disk but also has
> serious problems in listing directories with thousands of names: it
> hangs up.

There are several parameters you can adjust to perhaps make it perform
better. Also you might want to check which file system your NFS-server
is using on the slow partition. Some filesystems (e.g. ext2) perform
poorly when a directory contains many entries.

> 3. Which one is the fastest and most stable among NFS, FTP and SMB,
> for an use in a totally trusted environment (such as a LAN crossed
> cable)?

I use NFS because it is the easiest and most convinient for me to use.
I have several computers using the same NFS-server without any
stabibility problems.

--
Jacob

linuxnewbie1234 wrote:
> Hi all,
> is it possible in Linux, using a USB-to-USB cable, to have one of the
> two computers (A, the server) provide data to the other one (B)
> appearing to B as if there was a USB key connected?
>
> Something like sharing a directory but appearing to the outside like an
> USB-key

You would need a USB port on your computer that was capable of behaving
as a device rather than a master. AFAIK, such things are far from
common.

It also would be nearly impossible to permit concurrent changes on both
sides. Operating systems assume they have exclusive use of a USB device
and will not correctly detect you changing data out from underneath
them. (Why would they re-read something they think they already read?)
So unless you're just trying to present a fixed partition image, you
may be attempting the impossible.

DS

David Schwartz wrote:
> linuxnewbie1234 wrote:
> You would need a USB port on your computer that was capable of behaving
> as a device rather than a master.

There are USB-to-USB cables for sale, with electronics in the middle,
which are made exactly for two computers to be hooked together.

> It also would be nearly impossible to permit concurrent changes on both
> sides.

Of course.