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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120719012805.GD17430@twin.jikos.cz>
Date:	Thu, 19 Jul 2012 03:28:05 +0200
From:	David Sterba <dave@...os.cz>
To:	Mitch Harder <mitch.harder@...ayonlinux.org>
Cc:	dave@...os.cz, Arnd Hannemann <arnd@...dnet.de>,
	chris.mason@...ionio.com, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, ierdnah@...il.com
Subject: Re: [PATCH v2] Btrfs: allow mount -o remount,compress=no

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/