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-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html