syscall tracen

Nikolaus Rath

unread,

Jan 20, 2006, 9:50:20 AM1/20/06

to

Hallo,

Ich möchte eine über FTP erreichbare Datei als Blockdevice mounten.

Dazu habe ich den FTP Server mittels lufs gemountet und wollte jetzt
über losetup ein Blockdevice einrichten. Leider klappt das nicht. Wenn
immer die zu mountende Datei in einem lufs mountpoint liegt, schlägt
losetup fehl mit:

[0] nokile:~/mainbackup/remote/html$ losetup -f backup.aes
ioctl: LOOP_SET_FD: Invalid argument

Leider scheint lufs auch upstream ziemlich tot zu sein. Aber ganz im
Sinne des OpenSource Gedankens möchte ich jetzt versuchen, das selber
zu richten.

Ein strace ergab im wesentlichen:

open("backup.aes", O_RDWR|O_LARGEFILE) = 3
open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
mlockall(MCL_CURRENT|MCL_FUTURE) = 0
ioctl(4, 0x4c00, 0x3) = -1 EINVAL (Invalid argument)

Leider hänge ich jetzt auch schon fest. Eine ioctl manpage habe ich
auf meinem System nämlich nicht.

Wie kann ich nachvollziehen, aus welchem Grund der ioctl syscall
fehlschlägt?

Danke im Voraus,

--Nikolaus

--
Ein aufgeräumter Tisch bringt dir kein Lob ein. Im Gegenteil: Du kommst
in den Verdacht, zu wenig Arbeit zu haben

Holger Paulsen

unread,

Jan 20, 2006, 2:08:15 PM1/20/06

to

Nikolaus Rath <Niko...@rath.org> writes:

> Ein strace ergab im wesentlichen:
>
> open("backup.aes", O_RDWR|O_LARGEFILE) = 3
> open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
> mlockall(MCL_CURRENT|MCL_FUTURE) = 0
> ioctl(4, 0x4c00, 0x3) = -1 EINVAL (Invalid argument)
>

> Leider h .A NC N$nge ich jetzt auch schon fest. Eine ioctl manpage habe ich
> auf meinem System n .A NC N$mlich nicht.

Hm Schaun wir mal.

,----
| paulsen@deimos:~$ apropos ioctl
| blockdev (8) - call block device ioctls from the command line
| console ioctl (4) [console_ioctl] - ioctl's for console terminal and virtual consoles
| console_ioctl (4) - ioctl's for console terminal and virtual consoles
| tty ioctl (4) [tty_ioctl] - ioctls for terminals and serial lines
| tty_ioctl (4) - ioctls for terminals and serial lines
`----

Allerdings findet sicn in tty_ioctl(4) der Hinweis

,----
| WARNING
| Do not regard this man page as documentation of the Linux console
| ioctl $B!G (Bs. This is provided for the curious only, as an alternative to
| reading the source. Ioctl $B!G (Bs are undocumented Linux internals, liable to
| be changed without warning. (And indeed, this page more or less
| describes the situation as of kernel version 1.1.94; there are many
| minor and not-so-minor differences with earlier versions.)
`----

Das bedeutet wohl, da .A N_ man sich die Kernel-Sourcen anschauen
darf. Im Documentation-Ordner eines halbwegs aktuellen 2.6
findet sich sogar ein Unterordner ioctl sowie eine Datei
ioctl-number.txt, die aber an dieser Stelle anscheinend
nicht wirklich weiterf .A N|hrend sind.

Ein m .A Nvglicherweise erfolgversprechender Ansatz k Nvnnte u.U.
ein Studium von include/linux/loop.h sein.

.A NDh... was schreibe ich hier eigentlich wieder zusammen? Ich
habe vom Programmieren im allgemeinen und Debuggen im
speziellen *keine* Ahnung.

Holger

Alexander Skwar

unread,

Jan 23, 2006, 7:05:29 AM1/23/06

to

Holger Paulsen <pau...@mobile.in-berlin.de>:

> Nikolaus Rath <Niko...@rath.org> writes:
>
>> Ein strace ergab im wesentlichen:
>>
>> open("backup.aes", O_RDWR|O_LARGEFILE) = 3
>> open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
>> mlockall(MCL_CURRENT|MCL_FUTURE) = 0
>> ioctl(4, 0x4c00, 0x3) = -1 EINVAL (Invalid argument)
>>

>> Leider h��’s. This is provided for the curious only, as an alternative to
> | reading the source. Ioctl’s are undocumented Linux internals, liable to

> | be changed without warning. (And indeed, this page more or less
> | describes the situation as of kernel version 1.1.94; there are many
> | minor and not-so-minor differences with earlier versions.)
> `----
>

> Das bedeutet wohl, da��

Was ist denn da passiert? Ist der Artikel mit MID <news:dqr4ft$rkb$1...@mobile.in-berlin.de>
in de.comp.os.unix.linux.moderated bei euch fehlerfrei
darstellbar? Bei mir mit KNode nicht. Und ich kann dieses
Flup auch nicht versenden, da "Line too long"...

Ich vermute, dass das Problem daher rührt, das der Artikel
mit iso-2022-jp-2 kodiert wurde. Wurde er denn wenigstens
fehlerfrei kodiert? Wenn ja, dann würde ich gerne einen
weiteren Bug für KNode eintragen - der dann vermutlich genauso
vor sich hin rotten würde :(

XP de.comm.software.newsreader,de.comp.os.unix.linux.moderated
Flup2 de.comm.software.newsreader

Alexander Skwar
--
"Just out of curiosity does this actually mean something or have some
of the few remaining bits of your brain just evaporated?"
-- Patricia O Tuama, ri...@killer.DALLAS.TX.US