Q:

Map eSata interface directly to NFS share

I'm not sure if this is possible, but I want to mount a nfs share (as a client) and have the motherboard external eSata bound to the nfs share.
This likely sounds bogus, but is what I have is a media player that can playback media over eSata, and want to have an intermediary box that does the translation between eSata and a nfs mount.  (As this particular player knows nothing about the world of nfs).
Maybe there is a better way, so I'm open to suggestions.  (But it must not get away from nfs).
Another (more sloppy) idea I have is to find a external usb w/ eSata drive of the smallest possible size, and mount the nfs share with a symbolic link on the external drive, and then the media player eSata also feeding into the drive.
Thanks!

A:

While not fundamentally impossible, I don't believe that any solution do to this exists.
Firstly, if I'm understanding your request correctly -- the media player doesn't have it's own disk, or isn't using it here -- the media player expects to be presented a disk over eSATA. eSATA is a block-access protocol; to give it such a block device (a disk, that here isn't actually a disk), you need a SATA HBA on your end running in target mode ('normal' ports run in initiator mode). This is uncommon outside of SAN systems, and there they tend to be Fibre Channel or SAS, not SATA. These target-mode supporting setups map a (single, big) file to a LUN that is presented to the attached devices. The server doesn't know or care much about what's in that file; it's up to the client machine to make sense of the partition table and filesystem on the LUN before it can get to the actual contents of a file.
Next, the media server is probably expecting the 'disk' it's seeing to have a DOS-style partition table and a single partition with a FAT (or maybe NTFS) partition on it. Maybe it'll accept ext2/3 as well -- it depends on what it's running itself.
NFS, on the other hand, is a file protocol. A client requests a file and gets the raw data, without caring about the filesystem the file lives on.
In order to do what you want here, you need an intermediary layer which builds an internal structure of some filesystem layout the media player can read (the most likely options being non-open standards, which adds to the complexity), and answer requests for those blocks with data taken from files from NFS. You could enumerate the contents of the NFS mount to build the database, but any changes to the NFS share would need to get reincorporated into the representation fed to the media player. There are some syscalls in Linux that can do this, but they don't work with an NFS mount.
So, the way to do this safely would be to copy the contents of the NFS share into a loopback-mounted FAT32 partition, then unmount the partition and export it as a LUN to the media player. This has the downside of needing to store everything twice, however.
Or, in short: sorry, it's (pretty much) impossible.

