Chris Mason oracle.com> writes:
>
> People have already started picking up #4, fujitsu had some patches in
> this direction that we'll keep developing with.
>
> I stepped back to add some directory metadata fixups as well to the
> basic fsck tool. I had thought I could easily do it all from the
On 03/28/2012 06:24 AM, Matthias G. Eckermann wrote:
> Hello Alex and all,
>
> On 2012-03-27 T 17:19 + Alex wrote:
>
>> Just a quick question but can't find an obvious answer.
>>
>> Can I create/convert a existing (btrfs) directory into a
>> subvolume?
>>
>> It would be very helpful when tran
On Wed, Mar 28, 2012 at 5:24 AM, Matthias G. Eckermann wrote:
> While the time measurement might be flawed due to the subvol
> actions inbetween, caching etc.: I tried several times, and
> "cp --reflinks" always is multiple times faster than "mv" in
> my environment.
So this is cross-subvolume re
On Monday 2012-03-26 03:42, Liu Bo wrote:
>On 03/23/2012 08:07 PM, Jan Engelhardt wrote:
>> Observed on Linux 3.2.9 after the controller/disk flaked in-out.
>> (The world still needs a SCSI error decoding tool to tell normal people
>> what cmd and res are about.)
>>
>
>I'm not that sure if your
Hello Alex and all,
On 2012-03-27 T 17:19 + Alex wrote:
> Just a quick question but can't find an obvious answer.
>
> Can I create/convert a existing (btrfs) directory into a
> subvolume?
>
> It would be very helpful when transferring 'partitions'
> into btrfs. I found a similar question w
On Tue, Mar 27, 2012 at 12:19 PM, Alex wrote:
> Hi all,
>
> Just a quick question but can't find an obvious answer.
>
> Can I create/convert a existing (btrfs) directory into a subvolume?
>
> It would be very helpful when transferring 'partitions' into btrfs.
> I found a similar question way back
Thought I would let you know I did get things figured out. I used
btrfs-progs from github
https://github.com/josefbacik/btrfs-progs
I also used the findroot function from there which generated more
possibilities for the root objectid.
By pluging in the guesses from findroot into -r objectid for th
Hi all,
Just a quick question but can't find an obvious answer.
Can I create/convert a existing (btrfs) directory into a subvolume?
It would be very helpful when transferring 'partitions' into btrfs.
I found a similar question way back in google, but that site is
down now generally.
Thanks in a
Jan Schmidt writes:
> On 27.03.2012 18:24, cwillu wrote:
>> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth wrote:
>>> A scrub done the morning after the incident also didn't find any
>>> problems:
>>>
>>> root@mim:/home/cwg# btrfs scrub status /
>>> scrub status for 2da00153-f9ea-4d6c-a6cc-10c9
On 27.03.2012 18:24, cwillu wrote:
> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth wrote:
>> A scrub done the morning after the incident also didn't find any
>> problems:
>>
>> root@mim:/home/cwg# btrfs scrub status /
>> scrub status for 2da00153-f9ea-4d6c-a6cc-10c913d22686
>>scrub star
On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth wrote:
> I have a freshly installed system with btrfs as the root file system.
> The machine is running linux 3.2. The raid1 btrfs file system lives on
> two new hard drives.
>
> About one day after installation the following message appeared in
>
I had found that note on the restore but my restore.c does not allow
that flag (it is also missing the "m" flag as well), I used the branch
dangerousdonteveruse on
https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I
switched to the master branch to see if there was a difference but i
If relocate of block group 0 fails with ENOSPC we end up infinitely
looping because key.offset -= 1 statement in that case brings us back to
where we started.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/volumes.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/
Generally we don't allow dup for data, but mixed chunks are special and
people seem to think this has its use cases.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/volumes.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
ind
Do not run sanity checks on all target profiles unless they all will be
used. This came up because alloc_profile_is_valid() is now more strict
than it used to be.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/volumes.c | 27 +++
1 files changed, 11 insertions(+), 16 deletio
Currently if we don't have enough space allocated we go ahead and loop
though devices in the hopes of finding enough space for a chunk of the
*same* type as the one we are trying to relocate. The problem with that
is that if we are trying to restripe the chunk its target type can be
more relaxed t
"0" is a valid value for an on-disk chunk profile, but it is not a valid
extended profile. (We have a separate bit for single chunks in extended
case)
Also rename it to alloc_profile_is_valid() for clarity.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/ctree.h | 21 +
fs
Add __get_block_group_index() helper to be able to derive block group
index from an arbitary set of flags. Implement get_block_group_index()
in terms of it.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/extent-tree.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff -
Add get_restripe_target() helper and switch everybody to use it.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/extent-tree.c | 94 +--
1 files changed, 50 insertions(+), 44 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3
Header file is not a good place to define functions. This also moves a
call to alloc_profile_is_valid() down the stack and removes a redundant
check from __btrfs_alloc_chunk() - alloc_profile_is_valid() takes it
into account.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/ctree.h | 23 ---
Add functions to abstract the conversion between chunk and extended
allocation profile formats and switch everybody to use them.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/ctree.h | 15 +++
fs/btrfs/extent-tree.c | 25 +++--
fs/btrfs/volumes.c | 20 +
Hi Chris,
The main one here is the improvement to btrfs_can_relocate(), which is
now a tiny bit smarter and does not return ENOSPC when there's plenty of
unallocated space for target chunks. This, in addition to my patch
which disables silent profile "upgrades", should lower a number of
corner ca
In commit 4692cf58 we introduced new backref walking code for btrfs. This
assumes we're searching live roots, which requires a transaction context.
While scrubbing, however, we must not join a transaction because this could
deadlock with the commit path. Additionally, what scrub really wants to do
The two helper functions commit_cowonly_roots() and
create_pending_snapshot() failed to check the return value from
btrfs_cow_block(), which could at least in theory fail with -ENOSPC from
btrfs_alloc_free_block(). This commit adds the missing checks.
Signed-off-by: Jan Schmidt
---
fs/btrfs/tran
Hi Chris,
please pull my three current patches from my repo, based on your
for-linus branch (I can rebase them to the integration branch if that
helps):
git://git.jan-o-sch.net/btrfs-unstable for-chris
It's two really small fixes both mentioned earlier and a more or less
imporant fixup f
btrfs_init_lockdep only makes our lockdep class names look prettier, thus
it did never hurt we forgot to actually call it. This turns our lockdep
identifier strings from lockdep auto-set #[id] into really pretty
"btrfs-fs-01" or "btrfs-csum-03".
Signed-off-by: Jan Schmidt
---
fs/btrfs/super.c |
On Tue, Mar 27, 2012 at 05:58:17AM -0700, Not Zippy wrote:
> One entire subvolume was restored. But there were 4 subvolumes on that
> partition. Is there a way to specify/force the restore of a different
> subvolume ?
>
> find-root seems to only find a single root.
There is only a single root
One entire subvolume was restored. But there were 4 subvolumes on that
partition. Is there a way to specify/force the restore of a different
subvolume ?
find-root seems to only find a single root.
thanks
On Mon, Mar 26, 2012 at 3:47 PM, Hugo Mills wrote:
> On Mon, Mar 26, 2012 at 03:36:13PM -07
Roman Mamedov writes:
> On Tue, 27 Mar 2012 12:57:31 +0200
> Christoph Groth wrote:
>
>> root@mim:/# find / -inum 453509 -ls
>> 453509 1976 -rw-r--r-- 1 root root 2020832 Mar 7 21:11
>> /usr/lib/libreoffice/basis3.4/program/libsblx.so
>>
>> That file seems to be ok, there are no er
On Tue, 27 Mar 2012 12:57:31 +0200
Christoph Groth wrote:
> root@mim:/# find / -inum 453509 -ls
> 453509 1976 -rw-r--r-- 1 root root 2020832 Mar 7 21:11
> /usr/lib/libreoffice/basis3.4/program/libsblx.so
>
> That file seems to be ok, there are no errors when re-reading it.
How abou
I have a freshly installed system with btrfs as the root file system.
The machine is running linux 3.2. The raid1 btrfs file system lives on
two new hard drives.
About one day after installation the following message appeared in
kern.log. There were no other errors.
root@mim:/var/log# grep 'btr
31 matches
Mail list logo
