RE: Modifying FILEIO Backstore for iSCSI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Jonathan,

On Fri, 2012-11-16 at 19:50 +0000, Jonathan Haws wrote:
> For anyone who may be interested, here is what I ended up doing:
> 
> I replaced the .execute_rw and .get_blocks routines with my own
> routines that would take the LBA specified in the command, translate
> it to the actual file on my EXT4 filesystem, read the appropriate
> location in the file, and returned the result in the same manner as a
> FILEIO backstore.
> 
> Bottom line is - two changes to target_core_file.c, my own custom
> kernel module to house the custom routines and that is that.
> 

This is a pretty neat hack.  Nice work. :)

I'm really glad to see that you're able to customize the FILEIO backend
driver to suit your needs without too much trouble.  Also, thanks for
letting us know of your progress since the initial posting, and
apologies for the initial lack of response.

Thank you!

--nab

> FYI.
> 
> 
> ________________________________________
> From: target-devel-owner@xxxxxxxxxxxxxxx [target-devel-owner@xxxxxxxxxxxxxxx] on behalf of Jonathan Haws [Jonathan.Haws@xxxxxxxxxxx]
> Sent: Thursday, November 08, 2012 10:19
> To: target-devel@xxxxxxxxxxxxxxx
> Subject: Modifying FILEIO Backstore for iSCSI
> 
> iSCSI gurus,
> 
> I am working on a project that has requirements where I have to present an iSCSI target to initiators with a very specific "filesystem" - basically just an index of the files on the disk (read-only).  However, my device runs and logs data to an EXT4 filesystem and changing that to use this non-standard filesystem would be .
> 
> Here is my plan:
> 
> Modify the FILEIO backstore so that the initiator will see the expected index.  The initiator, when it tries to read a file, will issue the command as normal and my custom FILEIO backstore will accept the command and read the file from my EXT4 filesystem, instead of from the FILEIO "block device".  Essentially what I plan to create is a "translator" module that contains routines that are called at the appropriate point by the FILEIO module.
> 
> Clear as mud?
> 
> My question for the list is this:
> 
> Can someone point me to some documentation (or the correct source files) to be able to trace the path of SCSI commands as they come into the target?  What I am most interested in is where the actual SCSI read commands are "translated" to files on the backstore device.
> 
> Can some expert point me in the right direction so I don't waste time sifting through files that I won't be touching?  Does it make sense to simply replace the vfs_readv() call in fd_do_readv() with a call to MyTranslator_readv()?  I am guessing it would make better sense to intercept the command earlier - but where?
> 
> Thanks for the help!
> Jonathan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe target-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe target-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux