Bug 771641

(In reply to comment #0)
> Description of problem: loop device has ext_range of 1 == not partitionable
> 
> Version-Release number of selected component (if applicable):
> 3.1.6-1.fc16.x86_64
> 
> How reproducible: every time
> 
> Steps to Reproduce:
> 1. truncate -s10m a && t=$(losetup --show -f a)
> 2. cat /sys/devices/virtual/block/$(basename $t)/ext_range
> 3.
> 
> Actual results: 1
> 
> Expected results: 256
> 
> Additional info:
> 
> With the current behavior, one cannot partition a loop device on F16,
> but one can on rawhide.  This induces test failures at least with GNU parted.

The behavior that changes ext_range to 256 seems to be newly added in the 3.2 kernel.  F14 (2.6.35) also defaults to 1.  That's why rawhide shows different behavior.

It was added to loop.c in 3.2 with commit:

loop: always allow userspace partitions and optionally support automatic scanning (e03c8dd14915f)

which ors in the GENHD_FL_EXT_DEVT flag for the disk structure for the loop device.  That tells disk_max_part to always return DISK_MAX_PARTS (256), which is what ext_range represents.

Are you seeing this as a regression somewhere, or is GNU parted making an incorrect assumption?  I doubt this is an actual _bug_ in F16, since the desired behavior you expect is new...

If you really need to make F16 match, you can use the max_parts module parameter for the loop module I think.

(In reply to comment #1)
> (In reply to comment #0)
...
> > With the current behavior, one cannot partition a loop device on F16,
> > but one can on rawhide.  This induces test failures at least with GNU parted.
>
> The behavior that changes ext_range to 256 seems to be newly added in the 3.2
> kernel.  F14 (2.6.35) also defaults to 1.  That's why rawhide shows different
> behavior.

Hi Josh,
Thanks for the quick reply.

> It was added to loop.c in 3.2 with commit:
> loop: always allow userspace partitions and optionally support automatic
> scanning (e03c8dd14915f)

Ah ha.  For some reason, I thought that behavior was expected to be in 3.1.
Maybe because folks using some other distribution (one that typically lags
behind Fedora) were saying it worked fine for them.  Now, I have to conclude
that they were using a 3.2 kernel or 3.1 with that bit back-ported.

> which ors in the GENHD_FL_EXT_DEVT flag for the disk structure for the loop
> device.  That tells disk_max_part to always return DISK_MAX_PARTS (256), which
> is what ext_range represents.
>
> Are you seeing this as a regression somewhere, or is GNU parted making an
> incorrect assumption?  I doubt this is an actual _bug_ in F16, since the
> desired behavior you expect is new...

You're welcome to close it NOTABUG.

> If you really need to make F16 match, you can use the max_parts module
> parameter for the loop module I think.

The existing test does this, (it's "max_part")

    # If the loop module is loaded, unload it first
    if lsmod | grep '^loop[[:space:]]'; then
	rmmod loop || fail=1
    fi

    # Insert loop module with max_part > 1
    modprobe loop max_part=7 || fail=1

but that modprobe appears to have no effect on my F16 system:

    # lsmod|grep loop
    [Exit 1]
    # modprobe loop max_part=7
    # lsmod|grep loop
    [Exit 1]

we have it built-in.
does tweaking /sys/module/loop/parameters/max_part do what you need ?

Hi Dave,
Thanks for the suggestion.
Is there some trick to doing this?

   $ echo 7 > /sys/module/loop/parameters/max_part
   zsh: permission denied: /sys/module/loop/parameters/max_part
   [Exit 1]

bah, it's not writeable. That's unfortunate.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Thanks. With that update to 3.3, the test now passes.