After removing some of the snapshots that were received, the errors at
btrfs check went away.
Is there some list of features in btrfs which are considered stable?
Cause I though send/receive and the subvolumes would be, but apparently
this doesn't seem to be the case :-/
Cheers,
Chris.
Hi.
This is on a btrfs created and used with a 4.0 kernel.
Not much was done on it, apart from send/receive snapshots from another
btrfs (with -p).
Some of the older snapshots (that were used as parents before) have
been removed in the meantime).
Now a btrfs check gives this:
# btrfs check
Hi.
The following is a possible corruption of a btrfs with RAID6,... it may
however also be just and issue with the megasas driver or the PERC
controller behind it.
Anyway since RADI56 is quite new in btrfs, an expert may want to have a
look at it whether it's something that needs to be focused
On Mon, 2015-04-20 at 05:23 +, Duncan wrote:
Which, given the common developer wisdom about premature optimization,
can be explained. But accepting that explanation, one is still stymied
by the fact that all the previous warnings about btrfs being in heavy
development, keep good
On Sun, 2015-04-19 at 01:02 +1000, Russell Coker wrote:
An rsync on block devices wouldn't lose BTRFS checksums, you could run a
scrub
on the target at any time to verify them. For a dd or anything based on that
the target needs to be at least as big as the source. But typical use of
Hi.
As mentioned before on the list, I'm just playing with send/receive.
The first huge disappointment (after copying already hundreds of
gigabytes for hours) was, that when I Ctrl-Z the sending/receiving pipe
(to give the disks a little bit of rest to cool down) can resuming it
(fg) it
On Sat, 2015-04-18 at 10:20 -0600, Chris Murphy wrote:
Make the source a seed device, add new device, delete seed. Once that
completes, unmount, unset btrfs seed, and now the two devices are
separate fs volumes each with unique UUID. There may still be bugs
with seed device, it's been maybe 6
Hey.
I've seen that this has been asked some times before, and there are
stackoverflow/etc. questions on that, but none with a really good
answer.
How can I best copy one btrfs filesystem (with snapshots and subvolumes)
into another, especially with keeping the CoW/reflink status of all
files?
On Thu, 2015-04-09 at 16:33 +, Hugo Mills wrote:
btrfs sub find-new might be more helpful to you here. That will
give you the list of changed files; then just feed that list to your
existing bin-packing algorithm for working out what goes on which
disks, and you're done.
hmm that
On Sat, 2015-04-18 at 04:24 +, Russell Coker wrote:
dd works. ;)
There are patches to rsync that make it work on block devices. Of course
that
will copy space occupied by deleted files too.
I think both are not quite the solutions I was looking for.
Guess for dd this is obvious,
Hey.
I wondered whether this is possible in btrfs (or could be
implemented),... it's in a way similar to send/receive, but AFAIU not
fully solvable with that.
What I want to do is making incremental backups of a (btrfs) filesystem
to smaller mediums (that is for example: from a big RAID
On Sun, 2015-03-29 at 13:43 +0200, Kai Krakow wrote:
Concluding that: duperemove should probably not try to become smart about
filesystem boundaries. It should either cross them or not as it is now - the
option is left to the user (as is the task to supply proper cmdline
arguments with
On Sun, 2015-03-29 at 16:44 +0200, Kai Krakow wrote:
Yes, the chosen default is probably not the best for this kind of utility.
But I suppose it follows the principle of least surprise. At least every
utility I'm daily using (like find) follows this default route.
But the default with all
Hey.
For encryption we have dm-crypt and in principle I'm happy with having
that at the block device level below the filesystem - perhaps except for
any possible performance issues, especially when used with software RAID
(regardless of whether MD or btrfs')[0].
But obviously integrity
On Sat, 2014-11-29 at 13:00 -0800, John Williams wrote:
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com wrote:
Why not just use the kernel crypto API? Then the user can just specify any
hash the kernel supports.
One reason is that crytographic hashes are an order of
On Mon, 2014-12-01 at 16:43 -0800, Alex Elsayed wrote:
including that MAC-then-encrypt is fragile
against a number of attacks, mainly in the padding-oracle category (See: TLS
BEAST attack).
Well but here we talk about disk encryption... how would the MtE oracle
problems apply to that? Either
Agree with others about -C 256...-C sha256 is only three
letters more ;)
Ideally, sha2-256 would be used, since there will be (are) other
versions of sha which have 256 bits size.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Agree with others about -C 256...-C sha256 is only three
letters more ;)
Ideally, sha2-256 would be used, since there will be (are) other
versions of sha which have 256 bits size.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Sun, 2014-11-30 at 23:05 +, Dimitri John Ledkov wrote:
Nope, we should use standard names.
Well I wouldn't know that there is really a standardised name in the
sense that it tells it's mandatory.
People use SHA2-xxx, SHA-xxx, SHAxxx and probably even more
combinations.
And just because
Hey.
For some time now I consider to use btrfs at a larger scale, basically
in two scenarios:
a) As the backend for data pools handled by dcache (dcache.org), where
we run a Tier-2 in the higher PiB range for the LHC Computing Grid...
For now that would be rather boring use of btrfs (i.e. not
On Wed, 2014-06-25 at 08:47 +0100, Hugo Mills wrote:
This has variously been possible and not over the last few years. I
think it's finally come down on the side of not,
I think that would really be a loss... :(
The question is, why?
Well imagine you have some computer which can only
On Sat, 2014-06-07 at 10:25 +0200, Goffredo Baroncelli wrote:
You can add new ideas to the wiki pages, supporting by link and other info
were available. This is the real nature of the wiki pages.
I've added some stuff now:
On Tue, 2014-06-03 at 19:03 +0200, Goffredo Baroncelli wrote:
There is (was ?) a project to address that: richacl
http://www.bestbits.at/richacl/.
This is not a btrfs project, but a linux kernel project because from a
filesystem POV the implementation requires to store some information in
On Thu, 2014-06-05 at 07:56 -0700, Marc MERLIN wrote:
Dmcrypt is
ok, however add discard to cryptsetup options too
Be aware, that discard used with dm-crypt may have security
implications.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Hi.
Christian Kujau suggested in the wiki[] to post project ideas to the
list to give them some possible wider discussion.
So far I've had these ideas:
1) NFS 4 ACLs[1]
Not sure whether it has been proposed and/or rejected before),... but it
would be nice if it was a goal for btrfs to support
301 - 325 of 325 matches
Mail list logo
