On Sat, Mar 14, 2009 at 11:33 PM, Pietro m0nt0 Montorfano <span dir="ltr"><<a href="mailto:monto84@gmail.com">monto84@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Il giorno sab, 14/03/2009 alle 21.20 +0100, Kees Jongenburger ha<br>
scritto:<br>
> Hello Pietro,<br>
><br>
[snip]<br>
<div class="im">> This problem was also discussed on the LKML, but with no actual result<br>
><br>
> <a href="http://lkml.org/lkml/2008/4/5/21" target="_blank">http://lkml.org/lkml/2008/4/5/21</a><br>
><br>
> Greetings<br>
<br>
</div>Thanks for the info, i'll watch that topic!<br>
Just one question, why i've saw /dev/sdaz ? I work with storages like<br>
SAN and some of our customer are using linux, considering a multipath<br>
environment (1 LUN 4 path) and a multipathing software the 16 sd* device<br>
limit is easily reached, but i'm sure that i've saw devices<br>
like /dev/sdaz which are teorically impossible to be created reading the<br>
spec file. It was a RHEL, various version with the default kernel and<br>
i'm quite sure that the multipath sw didn't patch anything, so, how is<br>
this possible?<br>
<br></blockquote></div>This is different in that it uses the SCSI subsystem v.s directly MMC layer.<br>If you put our 7+ parditioned MMC/SD card in a usb card reader you should see you can access all the partitions.<br><br>
greetings<br>