On 10.07.2012 08:00, Christoph Hellwig wrote: > On Mon, Jul 09, 2012 at 11:46:08AM -0700, Andy Grover wrote: >> It looks like it only wants to allow the use of TYPE_DISK block >> devices >> for iblock. Is there another way from userspace to know if a block >> device is a disk vs. tape or optical? > > iblock should not care - it just submits bios. And pscsci already > does > it's own internal checks. Whilst on the subject userspace, I have exported it with fileio because I need buffered mode. I know it's a risk with data consistency, but I need the additional performance (15MB/s writes (~30MB/s via iblock btw - but that has no cache options whatsoever) and nearly 100MB/s with buffered (until the buffers are full - MD RAID-6 is performing horribly (for writes, reads are fine), local as well btw dd'ing zero's with 1MB block size does somewhere between 20-30MB/s). 8 disk RAID-6 probably has too much parity overhead. Converting it to RAID-5 but it's gonna take 8 days or so. Anyways, in targetcli I can add the fileio backstore just fine with buffered mode, but haven't found a way so far to see in targetcli whether it's buffered or not. Probably could check the files under sys (did check the backup files which sets them), but it isn't obviously named for me at least (but not a dev nor native english :)). It would be nice however is this were visible in targetcli. Also don't know if my previous comment was clear, I modified the rtslib python code. That library checks the major numbers against a list and throws an error if the major number of the device to be exported isn't on it. This doesn't seem to be a limitation of the kernel code thus, just the userspace code. If one were to inject the config straight into the appropiate /sys files it would probably just work right away. Not entirely sure on this as the backup file (which restores the settings at boot) shows a lot of things it sets in /sys but only after it creates a backstore with another command. Not sure if that command uses rtslib as well, if so, it might run the same checks. Kind regards -- 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
