Am 03.10.2013 14:13, schrieb sf...@users.sourceforge.net:
>
> Florian Klink:
>> But it seems to still load "loop" module as soon as I mount any branch
>> with aufs.
>
> Exactly.
>
>
>> I'm not really into kernel code, but think this happens because
>> test_overlap() from branch.c always calls au_test_loopback_overlap()
>> when you add any branch, not only a when adding a "loopback branch".
>> I there should be some check if it's really a loop branch, before
>> loading everything (if that is possible).
>
> Unfortunately, without loop module, it becomes impossible to check
> whether the added branch is loopback mounted or not since linux-3.11.
>
>
>> I tested again on a kernel with the same configuration, but without loop
>> module file existing in /lib/modules/... (to simulate for example an
>> initramfs that just wants to make a ro filesystem read-write by a tmpfs
>> or similar and therefore has no loop module inside). I got the following
>> error:
> :::
>> [ 69.996741] aufs au_test_loopback_overlap:39:mount[1519]:
>> loop_backing_file() is not defined
>> [ 69.996746] aufs test_add:279:mount[1519]: ../../images/arch-base is
>> overlapped
>
> In this case, the second message "... is overlapped" is meaningless.
> I will stop it.
Okay.
>
>
>> So in my opinion, if it should be made possible to compile aufs with
>> loop as a run-time-dependency, it should still work when it's not able
>> to access the dependency.
>
> I think I can understand what you mean.
> But I don't agree. The case you mentioned above looks like a broken
> system to me since the kernel is complied as BLK_DEV_LOOP=m but there is
> no loop module. I don't think it a good idea to support such broken
> system.
>
I wanted to say that it's a little bit strange that aufs needs to load
loop module as soon as it mounts anything (even not loop).
If you can't really find out if the branch is from a loopback directly
by the kernel, can you probably just let aufs check if "loop features"
exist/are already loaded, before checking the branch itself for overlap?
I'd think you can't be faced with a loopback mountpoint to use as branch
if loop is not known to the kernel ;-)
So probably something like
bool check_if_loopback_overlap(){
if(!kernel_has_loop_already_loaded_or_compiled_in()) {
//kernel doesn't know anything about loop, so branch
//can't be a loopback one
return false
}
//kernel currently has support for loop
else {
symbol_request();...
return really_check_overlap_now();
}
}
If something like that is not possible, I think it should at least be
documented that aufs needs loop module file on first mount if it was
compiled with BLK_DEV_LOOP=m
Florian
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
