Hi,
I have below queries. Could somebody help me in understanding.
1)
As per my understanding btrfs file system uses one chunk tree and one
extent tree for entire btrfs disk allocation.
Is this correct?
In, some article i read that future there will be more chunk tree/ extent
tree for single
On Fri, Apr 17, 2015 at 06:24:05AM +, sri wrote:
Hi,
I have below queries. Could somebody help me in understanding.
1)
As per my understanding btrfs file system uses one chunk tree and one
extent tree for entire btrfs disk allocation.
Is this correct?
Yes.
In, some article i
On 17/04/15 10:20, WangMike wrote:
Dear all,
We know that one cannot mount multiple btrfs file systems which contain the
same UUID (for example, snapshot ).
Is it possible to make use of mount namespace achieve that? means, if the
btrfs file system in different namespace can contain the same
Hugo Mills hugo at carfax.org.uk writes:
On Fri, Apr 17, 2015 at 06:24:05AM +, sri wrote:
Hi,
I have below queries. Could somebody help me in understanding.
1)
As per my understanding btrfs file system uses one chunk tree and
one
extent tree for entire btrfs disk allocation.
Dear all,
We know that one cannot mount multiple btrfs file systems which contain the
same UUID (for example, snapshot ).
Is it possible to make use of mount namespace achieve that? means, if the
btrfs file system in different namespace can contain the same UUID.
Thanks
Mike
On Fri, Apr 17, 2015 at 7:54 AM, Noah Massey noah.mas...@gmail.com wrote:
On Thu, Apr 16, 2015 at 7:33 PM, Dan Merillat dan.meril...@gmail.com wrote:
The inode is already found, use the data and make restore friendlier.
Signed-off-by: Dan Merillat dan.meril...@gmail.com
---
cmds-restore.c |
On 2015-04-16 14:48, Miguel Negrão wrote:
Hello,
I'm running a laptop, macbook pro 8,2, with ubuntu, on kernel
3.13.0-49-lowlatency. I have a USB enclosure containing two harddrives
(Icydock JBOD). Each harddrive runs their own btrfs file system, on top of
luks partitions. I backup one
Looks like XFS v5 and ext4 checksums include fs UUID throughout the
filesystem metadata. For XFS changing the UUID has been disabled in
xfs_admin whereas tune2fs supports changing it (which I'd think could
take quite a while). Btrfs supports it via seed device + device add +
removing seed which
If we have concurrent fsync calls against files living in the same subvolume,
we have some time window where we don't add the collected ordered extents
to the running transaction's list of ordered extents and return success to
userspace. This can result in data loss if the ordered extents complete
We have this check in the kernel but not in userspace, which makes fsck fail
when we wouldn't have a problem in the kernel. This was meant to catch this
case because it really isn't good, unfortunately it will require a design change
to fix in the kernel so in the meantime add this check so we
On Tue, Apr 14, 2015 at 09:19:12AM -0400, Austin S Hemmelgarn wrote:
On 2015-04-14 08:28, David Sterba wrote:
On Tue, Apr 14, 2015 at 01:44:32PM +0300, Lauri Võsandi wrote:
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream to confine the process and
minimize
On 04/17/2015 02:20 PM, Filipe Manana wrote:
If we have concurrent fsync calls against files living in the same subvolume,
we have some time window where we don't add the collected ordered extents
to the running transaction's list of ordered extents and return success to
userspace. This can
On Fri, Apr 17, 2015 at 09:19:11AM +, Hugo Mills wrote:
In, some article i read that future there will be more chunk tree/ extent
tree for single btrfs. Is this true.
I recall, many moons ago, Chris saying that there probably wouldn't
be.
More extent trees tied to a set of fs
We have this check in the kernel but not in userspace, which makes fsck fail
when we wouldn't have a problem in the kernel. This was meant to catch this
case because it really isn't good, unfortunately it will require a design change
to fix in the kernel so in the meantime add this check so we
We don't need to attach ordered extents that have completed to the current
transaction. Doing so only makes us hold memory for longer than necessary
and delaying the iput of the inode until the transaction is committed (for
each created ordered extent we do an igrab and then schedule an
Resize of a filesystem image does not work as expected. This has been
confusing and can have bad consequences as people have reported,
resizing the wrong filesystem.
Signed-off-by: David Sterba dste...@suse.cz
---
Documentation/btrfs-filesystem.asciidoc | 9 +++--
cmds-filesystem.c
If we have concurrent fsync calls against files living in the same subvolume,
we have some time window where we don't add the collected ordered extents
to the running transaction's list of ordered extents and return success to
userspace. This can result in data loss if the ordered extents complete
On Fri, Apr 17, 2015 at 7:26 PM, Josef Bacik jba...@fb.com wrote:
On 04/17/2015 02:20 PM, Filipe Manana wrote:
If we have concurrent fsync calls against files living in the same
subvolume,
we have some time window where we don't add the collected ordered extents
to the running transaction's
We don't need to attach ordered extents that have completed to the current
transaction. Doing so only makes us hold memory for longer than necessary
and delaying the iput of the inode until the transaction is committed (for
each created ordered extent we do an igrab and then schedule an
Hi Austin,
On 17-04-2015 12:31, Austin S Hemmelgarn wrote:
First, as mentioned in another reply to this, you should update your
kernel. I don't think that the kernel is what is causing the issue, but
it is an old kernel by BTRFS standards, and keeping up to date is
important with a
I've been running some simple tests in a virtual machine with btrfs raid1 and I
found the background correction behaviour to be a bit surprising. I've set up a
raid1 and stored a big file along with its sha256sum on the volume. If I
manually corrupt one of the underlying devices and run a btrfs
On Fri, 17 Apr 2015 21:46:08 +0200, ivarun_ml wrote:
But if I instead just read the file, then btrfs will still detect and
correct the corruption, but the device stats are not updated, and the
errors in the syslog have info-priority, making them much harder to
notice. [..]
I don't know about
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 Fri, 17 Apr 2015 11:08:44 PM Christoph Anton Mitterer wrote:
How can I best copy one btrfs filesystem (with snapshots and subvolumes)
into another, especially with keeping the CoW/reflink status of all
files?
dd works. ;)
And ideally incrementally upgrade it later (again with all
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,
26 matches
Mail list logo
