Re: [PATCH v2] Btrfs: allow mount -o remount,compress=no

[David Sterba]

On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote:
> I was testing the lz4(hc) patches, and I found the the compression
> INCOMPAT flags are not being updated using the method in this patch.
> 
> The compression INCOMPAT flags are generally checked and updated in
> the open_ctree() function.
> 
> But, on remount, open_ctree() is not called.

This currently happens with lzo as well, right?

* mount without any compression
* remount -o compress=lzo
* write data
* umount
* => filesystem has lzo data without incompat bit set

> I was going to test a patch to update the INCOMPAT flags similar to
> the way lzo INCOMPAT is updated when specifying the compress method in
> defragmentation.
> 
> http://kerneltrap.org/mailarchive/linux-btrfs/2010/11/18/6886194

This is clear that the incompatibility should be set, because the user
wants it so and the lz4 patches should do the same. I see that the hc
incompatibility does not though, that has to be fixed.

> But, let me know if it is preferred to just return -EINVAL when trying
> to remount with a compression method that has an INCOMPAT not yet seen
> by that volume.

Let's say it returns EINVAL upon remount, then I need to do umount/mount
with the desired option. Remount is usually not done by accident, so
similar to the defrag, I'd expect the operation to succeed, but I as a
user may not know that it brings a backward incompatibility. Getting rid
of an incompat is not straightfoward at all, so I understand the
caution.

My preference is to let remount succeed and set the incompat bit,
possibly with a KERN_INFO message to syslog in case the bit is yet
unseen by the volume.


david
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/