On 2015-12-05 07:01, Hugo Mills wrote:
On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer wrote:
On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
I don't think it'll cause problems.
Is there any guaranteed behaviour when btrfs encounters two filesystems
(i.e. not talking
Christoph Anton Mitterer posted on Wed, 09 Dec 2015 06:07:38 +0100 as
excerpted:
> Well as I've said, getting that in via USB may be only one way.
> We're already so far that GNOME automount devices when plugged...
Ugh. ... And many know that's the sort of thing that made MS so much of
a
On Sun, 2015-12-06 at 04:06 +, Duncan wrote:
> There's actually a number of USB-based hardware and software vulns
> out
> there, from the under $10 common-component-capacitor-based charge-
> and-zap
> (charges off the 5V USB line, zaps the port with several hundred
> volts
> reverse-polarity,
Christoph Anton Mitterer posted on Sat, 05 Dec 2015 04:28:24 +0100 as
excerpted:
> On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
>> I don't think it'll cause problems.
> Is there any guaranteed behaviour when btrfs encounters two filesystems
> (i.e. not talking about the subvols now) with
On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer wrote:
> On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
> > I don't think it'll cause problems.
> Is there any guaranteed behaviour when btrfs encounters two filesystems
> (i.e. not talking about the subvols now) with the
On Sat, 2015-12-05 at 13:19 +, Duncan wrote:
> The problem with btrfs is that because (unlike traditional
> filesystems)
> it's multi-device, it needs some way to identify what devices belong
> to a
> particular filesystem.
Sure, but that applies to lvm, or MD as well... and I wouldn't know
On Sat, 2015-12-05 at 12:01 +, Hugo Mills wrote:
> On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer
> wrote:
> > On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
> > > I don't think it'll cause problems.
> > Is there any guaranteed behaviour when btrfs encounters two
> >
Christoph Anton Mitterer posted on Sun, 06 Dec 2015 02:51:20 +0100 as
excerpted:
> You have things like ATMs, which are physically usually quite well
> secured, but which do have rather easily accessible maintenance ports.
> All of us have seen such embedded devices rebooting themselves, where
>
Hello
As we know, two file systems with the same UUID (like reported by eg. "blkid")
are problematic, especially if both are mounted at the same time it leads to
data corruption. So, copying a BTRFS partition with eg. dd to another and use
it immediately is bad. To prevent this, "btrfstune -u
On Fri, Dec 04, 2015 at 01:05:28PM +0100, S.J wrote:
> Hello
>
> As we know, two file systems with the same UUID (like reported by eg.
> "blkid") are problematic, especially if both are mounted at the same time it
> leads to data corruption. So, copying a BTRFS partition with eg. dd to
>
On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
> I don't think it'll cause problems.
Is there any guaranteed behaviour when btrfs encounters two filesystems
(i.e. not talking about the subvols now) with the same UUID?
Given that it's long standing behaviour that people could clone
Thinking a bit more I that, I came to the conclusion that it's actually
security relevant that btrfs deals gracefully with filesystems having the same
UUID:
Getting to know someone else's filesystem's UUID may be more easily possible
than one may think.
It's usually not considered secret and
--
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
I don't know how to fix this but I've convinced myself there's at
least a small problem. And not just with LVM snapshots as in the
originating thread.
- Via seed device method of creating a Btrfs volume, the resulting
volume gets a new UUID. The volume UUID from the seed device doesn't
pass
On 11/22/2014 02:50 PM, Robert White wrote:
Take a couple snapshots of a subvolume, and then
send those subvolumes to another file system with send/receive, and then
do btrfs subvolume list -u -q on the two filesystems and tell me that
mess makes sense. Or try to recreate a subvolume from its
15 matches
Mail list logo
