Re: Poll: time to switch skinny-metadata on by default?
On 22 October 2014 04:08, Duncan 1i5t5.dun...@cox.net wrote: Since the kernel has code for both fat metadata and skinny-metadata, they can exist side-by-side and the kernel will use whichever code is appropriate. I understand that the fat extent code will probably never be removed for compatibility reasons, but do wonder why it's still the default. Caution? Petr Janecek's balancing problem [1] and similar bugs aside: is there a functional reason to prefer fat over skinny metadata for future file systems? Regards, T G-R [1] http://www.spinics.net/lists/linux-btrfs/msg38443.html -- 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
Re: [PATCH 4/4] Default to acting like fsck.
On 21 September 2014 03:01, Dimitri John Ledkov x...@debian.org wrote:
Inspect arguments, if we are not called as btrfs, then assume we are
called to act like fsck.
[...]
- if (!strcmp(bname, btrfsck)) {
+ if (strcmp(bname, btrfs) != 0) {
That's assuming a lot.
Silently (!) breaking people's btrfs-3.15_patched-DontRandomlyPanicV2
is a recipe for needless hair-pulling. Is there a reason for not using
something less like strstr(bname, fsck) that I am missing?
Regards,
T G-R
--
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
Re: [RFC PATCH] Revert btrfs: allow mounting btrfs subvolumes with different ro/rw options
[List CCd. I hate Gmail.] Noob alert. On 3 July 2014 02:28, Qu Wenruo quwen...@cn.fujitsu.com wrote: Subject: Re: [RFC PATCH] Revert btrfs: allow mounting btrfs subvolumes w= ith different ro/rw options From: Goffredo Baroncelli kreij...@libero.it To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org Date: 2014=E5=B9=B407=E6=9C=8803=E6=97=A5 01:48 On 07/01/2014 11:30 AM, Qu Wenruo wrote: This commit has the following problem: 1) Break the ro mount rule. When users mount the whole btrfs ro, it is still possible to mount subvol rw and change the contents. Which make the whole fs ro mount non-sense. Where is the problem ? I see an use case when I want a conservative default: mount all ro except some subvolumes. In any case it is not a security problem because if the user has the capability to mount a subvolume, also he has the capability to remount,r= w the whole filesystem. Not security problem but behavior not consistent. If user mount the whole disk ro, he or she want the fs read only and noth= ing will change in it. If you mount a subvol rw, then the whole disk ro expectation is broken. Things will change even the whole disk is readonly. This assumption seems wrong and untenable if considered from a different angle: one doesn't mount the whole disk ro, merely the default subvolume. # mount -o ro /dev/sda1 /mnt is merely convenient short-hand for # mount -o ro,subvol=3D@ [or whatever] /dev/sda1 /mnt and anyone who expects this to magically protect the whole disk is, frankly, confused. Substituting partitions for subvolumes: mounting /dev/sda2 read-only should have no effect on /dev/sda3. Even if you went a bit batty and decided to make /dev/sda2 the default partition: # ln -sf /dev/sda2 /dev/sda # mount -o ro /dev/sda /mnt/this/is/silly syntactic sugar doesn't change anything. Subvolumes are logically discrete entities, the fact that they share trees on-disk is merely a (very nice) implementation detail. It is impossible to mount a whole disk under btrfs. Tobias The problem also happens when a parent subvol is mounted rw but child sub= vol is mounted ro. User can still modify the child subvol through parent subvol, still broke the readonly rule. This makes sense, though. -- 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
Re: [RFC PATCH] Revert btrfs: allow mounting btrfs subvolumes with different ro/rw options
On 3 July 2014 10:33, Qu Wenruo quwen...@cn.fujitsu.com wrote: Oh, sorry for my confusing words. And I probably should have waited for my frustration with my mail client/device/public transport to subside before panicking^Creplying. I use a combination of ro rw (not insanely nested) subvolumes on a few pseudo-embedded home/office servers and would like to keep that arrangement working if possible. I'm also aware that it doesn't protect against all possible bugs. To make it clear, when mentioning 'the whole disk(or partition whatever)' I mean the FS_TREE. (Of course not the default subvolume) The problem is that, even you mount a subvolume ro, you can still change contents in the subvolume through its rw parent subvolume. And if a subvolume can still be modified, the ro mount lose it meaning. That makes so much more sense than my original reading, which was weird and wrong and implied strange subvol-5-only magic. Sorry! So we need special rules to prevent such things. Not that it matters, but: agreed. Tobias -- 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
