Diego Calleja wrote:
> kmemleak found this:
> unreferenced object 0x8801b64af968 (size 512):
> comm "btrfs-cleaner", pid 3317, jiffies 4306810886 (age 903.272s)
> hex dump (first 32 bytes):
> 00 82 01 07 00 ea ff ff c0 83 01 07 00 ea ff ff
> 80 82 01 07 00 ea ff ff
On 09/02/2011 01:38 AM, Mitch Harder wrote:
> On Sat, Aug 6, 2011 at 4:37 AM, Liu Bo wrote:
>> I've fixed a bug and rebased this to the latest for-linus branch,
>> and with applying my previous posted patch:
>>
>>[PATCH] Btrfs: fix an oops of log replay
>>
>> , I also test this sub transac
Is there any way to monitor the progress of outstanding 'btrfs subvolume
delete' commands? I realize that figuring out when they complete is
somewhat non-linear in nature given the tree structures involved, but
even some information about forward progress would be useful at times.
--
Bruce Guen
On Thu, Sep 01, 2011 at 03:24:28PM -0500, Michael Cronenworth wrote:
> On 09/01/2011 03:20 PM, Hugo Mills wrote:
> >You may have missed the "on vacation" bit.
>
> I did read the "on vacation" bit. Not that it is any of my business,
> but how long is that vacation?
Your guess is as good as
On 09/01/2011 03:20 PM, Hugo Mills wrote:
You may have missed the "on vacation" bit.
I did read the "on vacation" bit. Not that it is any of my business, but
how long is that vacation?
The canonical place to look for btrfsck updates is the relevant FAQ
item on the btrfs wiki.
I kn
On Thu, Sep 01, 2011 at 02:14:00PM -0500, Michael Cronenworth wrote:
> On 08/25/2011 10:06 AM, Michael Cronenworth wrote:
> >
> >Is there an update on this? I don't see any new code for
> >btrfs-progs-unstable, but I might be looking in the wrong place.
> >
> >Will this fsck tool be able to handle
On 08/25/2011 10:06 AM, Michael Cronenworth wrote:
Is there an update on this? I don't see any new code for
btrfs-progs-unstable, but I might be looking in the wrong place.
Will this fsck tool be able to handle problems such as:
"parent transid verify failed on # wanted # found #" ?
Does a
Aren't the subjects like "[PATCH" and "[GIT" specifically so people
can filter the messages how they see fit?
On Thu, Sep 1, 2011 at 9:01 AM, Swâmi Petaramesh wrote:
> Hi list,
>
> Could it be considered to create a low-volume, "user-oriented" mailing-list
> that wouldn't spit an email for each a
On Sat, Aug 6, 2011 at 4:37 AM, Liu Bo wrote:
> I've fixed a bug and rebased this to the latest for-linus branch,
> and with applying my previous posted patch:
>
> [PATCH] Btrfs: fix an oops of log replay
>
> , I also test this sub transaction patchset with
> a) sysbench 0.4.12 tool and
> b
btrfsck status updates don't appear too often on the mailing list. But
when they do, they end up in the btrfs wiki page anyway. That's where
users like you and I should look.
I like hanging out here just to see what's coming from upstream
On Thu, Sep 1, 2011 at 10:01 AM, Swâmi Petaramesh wrote:
>
Hi list,
Could it be considered to create a low-volume, "user-oriented" mailing-list
that wouldn't spit an email for each and every git pull or patch, which are of
interest to developpers only, and of no interest at all for users ?
I personally am in need of information about BTRFS, i.e. new fe
Changelog v8->v9:
- bugfix: increment extent buffer's ref-count so it can safely be used after
releasing the path (reported by myself)
- fixed function comment for paths_from_inode()
This patch set with the recent fixes just mentioned is also available from the
scrub branch of my repository:
gi
the rest of the code uses int mirror_num, and so should scrub
Signed-off-by: Jan Schmidt
---
fs/btrfs/scrub.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 59caf8f..41a0114 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/sc
While scrubbing, we may encounter various errors. Previously, a logical
address was printed to the log only. Now, all paths belonging to that
address are resolved and printed separately. That should work for hardlinks
as well as reflinks.
Signed-off-by: Jan Schmidt
---
fs/btrfs/scrub.c | 169 ++
This removes a FIXME comment and introduces the first part of nodatasum
fixup: It gets the corresponding inode for a logical address and triggers a
regular readpage for the corrupted sector.
Once we have on-the-fly error correction our error will be automatically
corrected. The correction code is
These helper functions iterate back references and call a function for each
backref. There is also a function to resolve an inode to a path in the
file system.
Signed-off-by: Jan Schmidt
---
fs/btrfs/Makefile |3 +-
fs/btrfs/backref.c | 776 +
Currently, extent_read_full_page always assumes we are trying to read mirror
0, which generally is the best we can do. To add flexibility, pass it as a
parameter. This will be needed by scrub fixup code.
Signed-off-by: Jan Schmidt
---
fs/btrfs/disk-io.c |2 +-
fs/btrfs/extent_io.c |6 +
these ioctls make use of the new functions initially added for scrub. they
return all inodes belonging to a logical address (BTRFS_IOC_LOGICAL_INO) and
all paths belonging to an inode (BTRFS_IOC_INO_PATHS).
Signed-off-by: Jan Schmidt
---
fs/btrfs/ioctl.c | 143 ++
Fix the mirror_num determination in scrub_stripe. The rest of the scrub code
did not use mirror_num for anything important and that error went unnoticed.
The nodatasum fixup patch of this set depends on a correct mirror_num.
Signed-off-by: Jan Schmidt
---
fs/btrfs/scrub.c | 12 ++--
1
In normal operation, scrub is reading data sequentially in large portions.
In case of an i/o error, we try to find the corrupted area(s) by issuing
page sized read requests. With this commit we increment the
unverified_errors counter if all of the small size requests succeed.
Userland patches carr
kmemleak found this:
unreferenced object 0x8801b64af968 (size 512):
comm "btrfs-cleaner", pid 3317, jiffies 4306810886 (age 903.272s)
hex dump (first 32 bytes):
00 82 01 07 00 ea ff ff c0 83 01 07 00 ea ff ff
80 82 01 07 00 ea ff ff c0 87 01 07 00 ea ff ff ...
two new commands that make use of the new path resolving functions
implemented for scrub, doing the resolving in-kernel. the result for both
commands is a list of files belonging to that inode / logical address.
Signed-off-by: Jan Schmidt
---
btrfs-list.c | 35 +++
btrfs.c | 10
split list_subvols to separate functions and allow printing only in the
containing function. lets us make use of those functions when resolving
logical addresses.
Signed-off-by: Jan Schmidt
---
btrfs-list.c | 103 ++
1 files changed, 68 in
Added "inspect-internal inode-resolve" and "inspect-internal
logical-resolve" to the btrfs(8) man page.
Signed-off-by: Jan Schmidt
---
man/btrfs.8.in | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 84a60c
This version is still based on Hugo's current integration branch and can also be
pulled from git://git.jan-o-sch.net/btrfs-progs-unstable.
Changes v3->v4:
- bugfix: don't overwrite parent_id after setting it correctly in resolve_root
(reported by David Sterba)
Changes v2->v3:
- adapted to a cha
Revise the patch according to kernel side change.
Signed-off-by: Jie Liu
---
btrfs.c |7 +++
btrfs_cmds.c | 34 ++
btrfs_cmds.h |1 +
ctree.h |4
ioctl.h |2 ++
mkfs.c | 19 ---
utils.c |
unscribe linux-btrfs
--
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
Thanks again for your nice comments!
The wiki update is in progress.
Btw, is it make sense to improve the "struct btrfs_ioctl_fs_info_args"
to retrieve the label info through BTRFS_IOC_FS_INFO?
Would you please review the revised version?
Signed-off-by: Jie Liu
---
fs/btrfs/ctree.h |4
On Thu, Sep 01, 2011 at 05:18:38PM +0800, Jeff Liu wrote:
> Hi Hugo,
>
> On 09/01/2011 05:00 PM, Hugo Mills wrote:
> >On Thu, Sep 01, 2011 at 04:47:47PM +0800, Jeff Liu wrote:
> >>Hello,
> >>
> >>I'd like to introduce a new ioctl to set file system label.
> >>With this feature, we can execute `btr
Hi Hugo,
On 09/01/2011 05:00 PM, Hugo Mills wrote:
On Thu, Sep 01, 2011 at 04:47:47PM +0800, Jeff Liu wrote:
Hello,
I'd like to introduce a new ioctl to set file system label.
With this feature, we can execute `btrfs filesystem label [label]
[path]` through btrfs tools to set or change the lab
On Thu, Sep 01, 2011 at 04:47:47PM +0800, Jeff Liu wrote:
> Hello,
>
> I'd like to introduce a new ioctl to set file system label.
> With this feature, we can execute `btrfs filesystem label [label]
> [path]` through btrfs tools to set or change the label.
>
> Signed-off-by: Jie Liu
>
> ---
>
Hello,
This patch make use of the new ioctl(2) to set Btrfs label via `btrfs
filesystem label` command.
Signed-off-by: Jie Liu
---
btrfs.c |7 +++
btrfs_cmds.c | 27 +++
btrfs_cmds.h |1 +
ctree.h |6 ++
ioctl.h |2 ++
mkfs.c
Hello,
I'd like to introduce a new ioctl to set file system label.
With this feature, we can execute `btrfs filesystem label [label]
[path]` through btrfs tools to set or change the label.
Signed-off-by: Jie Liu
---
fs/btrfs/ctree.h |6 ++
fs/btrfs/ioctl.c | 37 ++
33 matches
Mail list logo
