(cc Arne for far-progs discussion)
On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
On 6/6/13 10:20 AM, Jan Schmidt wrote:
Basic send / receive functionality test for btrfs. Requires current
version of fsstress built (-x support). Relies on fssum tool, which is
not part of the test
Mapping UUIDs to subvolume IDs is an operation with a high effort
today. Today, the algorithm even has quadratic effort (based on the
number of existing subvolumes), which means, that it takes minutes
to send/receive a single subvolume if 10,000 subvolumes exist. But
even linear effort would be
If the filesystem was mounted with an old kernel that was not
aware of the UUID tree, this is detected by looking at the
uuid_tree_generation field of the superblock (similar to how
the free space cache is doing it). If a mismatch is detected
at mount time, a thread is started that does two
In order to be able to detect the case that a filesystem is mounted
with an old kernel, add a uuid-tree-gen field like the free space
cache is doing it. It is part of the super block and written with
each commit. Old kernels do not know this field and don't update it.
Signed-off-by: Stefan
This commit adds support to print UUID tree elements to print-tree.c.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/print-tree.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/fs/btrfs/print-tree.c
This tree is not created by mkfs.btrfs. Therefore when a filesystem
is mounted writable and the UUID tree does not exist, this tree is
created if required. The tree is also added to the fs_info structure
and initialized, but this commit does not yet read or write UUID tree
elements.
Mapping UUIDs to subvolume IDs is an operation with a high effort
today. Today, the algorithm even has quadratic effort (based on the
number of existing subvolumes), which means, that it takes minutes
to send/receive a single subvolume if 10,000 subvolumes exist. But
even linear effort would be
When a new subvolume or snapshot is created, a new UUID item is added
to the UUID tree. Such items are removed when the subvolume is deleted.
The ioctl to set the received subvolume UUID is also touched and will
now also add this received UUID into the UUID tree together with the
ID of the
When the UUID tree is initially created, a task is spawned that
walks through the root tree. For each found subvolume root_item,
the uuid and received_uuid entries in the UUID tree are added.
This is such a quick operation so that in case somebody wants
to unmount the filesystem while the task is
On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
(cc Arne for far-progs discussion)
On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
On 6/6/13 10:20 AM, Jan Schmidt wrote:
Basic send / receive functionality test for btrfs. Requires current
version of fsstress built
This should never be needed, but since all functions are there
to check and rebuild the UUID tree, a mount option is added that
allows to force this check and rebuild procedure.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/disk-io.c | 3 ++-
On Thu, Jun 06, 2013 at 07:51:28PM -0700, George Mitchell wrote:
I want to eliminate the COW feature on all of my OS files. It is a nice
feature for user files, but I don't see a clear benefit for the actual OS
files. And I suspect that COW induced fragmentation is causing or
aggravating
Thanks, I would never have understood the phrase it is undefined when
the blocks assigned to the file will be fully stable without your
further explanation. The man page could be far clearer in its choice of
wording. At this point I have also discovered that setting the nocow
flag also
On Fri, Jun 07, 2013 at 04:27:50AM -0600, Stefan Behrens wrote:
When the UUID tree is initially created, a task is spawned that
walks through the root tree. For each found subvolume root_item,
the uuid and received_uuid entries in the UUID tree are added.
This is such a quick operation so that
On Fri, Jun 07, 2013 at 04:27:51AM -0600, Stefan Behrens wrote:
In order to be able to detect the case that a filesystem is mounted
with an old kernel, add a uuid-tree-gen field like the free space
cache is doing it. It is part of the super block and written with
each commit. Old kernels do
On 06/07/2013 16:39, Josef Bacik wrote:
On Fri, Jun 07, 2013 at 04:27:51AM -0600, Stefan Behrens wrote:
In order to be able to detect the case that a filesystem is mounted
with an old kernel, add a uuid-tree-gen field like the free space
cache is doing it. It is part of the super block and
On Fri, Jun 07, 2013 at 08:41:52AM -0600, Stefan Behrens wrote:
On 06/07/2013 16:39, Josef Bacik wrote:
On Fri, Jun 07, 2013 at 04:27:51AM -0600, Stefan Behrens wrote:
In order to be able to detect the case that a filesystem is mounted
with an old kernel, add a uuid-tree-gen field like the
On 6/7/13 5:29 AM, Dave Chinner wrote:
On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
(cc Arne for far-progs discussion)
On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
On 6/6/13 10:20 AM, Jan Schmidt wrote:
Basic send / receive functionality test for btrfs.
On 07.06.2013 16:50, Eric Sandeen wrote:
On 6/7/13 5:29 AM, Dave Chinner wrote:
On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
(cc Arne for far-progs discussion)
On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
On 6/6/13 10:20 AM, Jan Schmidt wrote:
Basic send /
On Fri, June 07, 2013 at 16:51 (+0200), Arne Jansen wrote:
On 07.06.2013 16:50, Eric Sandeen wrote:
On 6/7/13 5:29 AM, Dave Chinner wrote:
On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
(cc Arne for far-progs discussion)
On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen
On Thu, 6 June 2013 22:49:22 +0300, Andy Shevchenko wrote:
On Thu, Jun 6, 2013 at 9:12 PM, Jörn Engel jo...@logfs.org wrote:
On Thu, 6 June 2013 22:32:55 +0300, Andy Shevchenko wrote:
On Mon, Jun 3, 2013 at 8:28 PM, Joern Engel jo...@logfs.org wrote:
I have seen a lot of boilerplate code
On Fri, Jun 7, 2013 at 7:36 PM, Jörn Engel jo...@logfs.org wrote:
On Thu, 6 June 2013 22:49:22 +0300, Andy Shevchenko wrote:
On Thu, Jun 6, 2013 at 9:12 PM, Jörn Engel jo...@logfs.org wrote:
On Thu, 6 June 2013 22:32:55 +0300, Andy Shevchenko wrote:
What the problem to use
On Fri, 7 June 2013 21:30:16 +0300, Andy Shevchenko wrote:
spin_lock
list_for_each_entry_safe
list_del
spin_unlock
Who is doing such thing?
Replace list_for_each_entry_safe with 'while (!list_empty(...))' and
just grep. My patch is about 'while (!list_empty(...))',
On 05/06/13 22:12, Martin wrote:
On 05/06/13 17:24, David Sterba wrote:
On Wed, Jun 05, 2013 at 04:43:29PM +0100, Hugo Mills wrote:
OK, so you've got plenty of space to allocate. There were some
issues in this area (block reserves and ENOSPC, and I think
specifically addressing the issue
On Fri, Jun 7, 2013 at 9:48 PM, Jörn Engel jo...@logfs.org wrote:
On Fri, 7 June 2013 21:30:16 +0300, Andy Shevchenko wrote:
spin_lock
list_for_each_entry_safe
list_del
spin_unlock
Who is doing such thing?
Replace list_for_each_entry_safe with 'while
25 matches
Mail list logo
