[Pkg-mc-devel] Bug#805495: mc: Very slow opening of an ISO file

[Thomas Schmitt]

Hi,

> With isoinfo the time to copy
> the pool directory from debian-8.2.0-i386-netinst.iso is about 26s.
> [...]
>   xorriso -osirrox on -indev debian-8.2.0-i386-netinst.iso -extract pool DESTINATION
> takes a mere 2s.

This is a situation where ISO tree loading of xorriso is superior
to repeated disk i/o of isoinfo.


> Using xorriso [under mc] the time taken is about 40s.

Possibly mc is running one xorriso process per data file,
rather than letting it extract the whole directory tree.


> I could understand isoinfo being slowish because I think it copies files
> one by one, but surely xorriso is capable of better integration into mc?

The ideal candidate would be
  xorriso -dialog on
attached via two pipes.
There are examples in
  http://libburnia-project.org/browser/libisoburn/trunk/frontend
for C (frontend_pipes_xorriso.c ),
for bash (sh_on_named_pipes.sh),
and for Tcl/Tk (xorriso-tcltk).


> /usr/lib/mc/extfs.d/iso9660

This here seems outdated:
  http://repo.or.cz/midnight-commander.git/tree/refs/heads/master:/src/vfs/extfs/helpers/iso9660.in
More modern:
  https://www.midnight-commander.org/browser/src/vfs/extfs/helpers/iso9660.in

It seems that the abstraction of filesystem operations
applies to single file objects. It is not obvious whether
mc will apply the methods to whole directory trees or
rather will walk the trees and process single data files.

Quite disturbing are the methods xorriso_copyin, xorriso_mkdir,
xorriso_rmdir, and xorriso_rm. (Why isn't there xorriso_mv ?)
They add a whole new session to the ISO in order to add their
file object to the ISO. Each time, the whole ISO filesystem tree
will be written. (Not to speak of the limitations of optical
media in respect to number of sessions.)

---------------------------------------------------------

Roadmap proposal for performance improvement:

- Have a dedicated xorriso slave process attached by two
  (named ?) pipes.
  Start it on first use of a iso9660 method as
   xorriso -abort_on FATAL -dialog on -osirrox on \
           ...maybe.more.initial.commands...

- Send xorriso commands into the stdin pipe of xorriso
  rather than starting a new xorriso process:
    -dev stdio:"$1"
    -cd "$dir" -lsl --
    -extract "$2" "$3"
    -cpr "$3" "$2" --
    -mkdir "$2" --
    -rmdir "$2" --
    -rm "$2" --
  (mc's iso9660 omits the parameter list delimiter "--"
   of commands with variable length parameter list.
   This is allowed only with the last command in a line,
   but is sloppy and might lure future programmers into
   errors. Better is to fully comply to the manual here.)

- Keep track which ISO filesystem image is currently opened
  by -dev.
  Perform command -dev only if the ISO image file differs
  from the one of the previous iso9660 method call.
  This will also -commit pending changes from xorriso_copyin.
  One might want to ask the user whether to -rollback instead.

- Maybe offer a method to -commit or -rollback on user wish ?

- Maybe omit "stdio:" from the -dev parameter in order to
  allow direct operation on optical media at /dev/srX.

- Perform xorriso command -end (or -rollback_end) when mc ends.
  This will end the xorriso slave.

xorriso commands -rollback and -rollback_end prevent writing
of pending changes from xorriso_copyin, xorriso_mkdir,
xorriso_rmdir, or xorriso_rm.
Commands -dev, -commit, or -end write a session if such changes
were made.

Pending changes will be shown with commands like -lsl or -du
as soon as they are caused by 


I wonder why xorriso_copyin uses -cpr rather than -map,
which would be the direct complement of -extract used by
xorriso_copyout.
The semantics of -cpr and -cp_rx differ from those of
-map and -extract if the target is a directory.
-cp* do like shell command cp: Put all files into directory.
-map/-extract do it more straightly: Replace directory or fail.


Have a nice day :)

Thomas