Martin posted on Sun, 29 Sep 2013 03:10:37 +0100 as excerpted:
> So...
>
> Any options for btrfsck to fix things?
>
> Or is anything/everything that is fixable automatically fixed on the
> next mount?
>
> Or should:
>
> btrfs scrub /dev/sdX
>
> be run first?
>
> Or?
>
>
> What does btrfs d
As we're hold a ref on looking up the extent map, we need to drop the ref
before returning to callers.
Signed-off-by: Liu Bo
---
v2: add the missing changelog.
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 0431147..ee1fdac
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 0431147..ee1fdac 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4483,6 +4483,7 @@ int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64
Chris,
Thanks for good comment/discussion.
On 29/09/13 03:06, Chris Murphy wrote:
>
> On Sep 28, 2013, at 4:51 PM, Martin wrote:
>
> Stick with forced 3Gbps, but I think it's worth while to find out
> what the actual problem is. One day you forget about this 3Gbps SATA
> link, upgrade or regr
On 28/09/13 23:54, Martin wrote:
> On 28/09/13 20:26, Martin wrote:
>
>> ... btrfsck bombs out with LOTs of errors...
>>
>> How best to recover from this?
>>
>> (This is a 'backup' disk so not 'critical' but it would be nice to avoid
>> rewriting about 1.5TB of data over the network...)
>>
>>
>> I
On Sep 28, 2013, at 4:51 PM, Martin wrote:
> Indeed. However, are not the sata errors reported back to btrfs so that
> it knows whatever parts haven't been updated?
It's a good question.
My doubtful speculation of such a mechanism is that it is really not the
responsibility of the file system
On Sun, Sep 29, 2013 at 01:35:15AM +0200, Aastha Mehta wrote:
> Hi,
>
> I have few questions regarding logging triggered by calling fsync in BTRFS:
>
> 1. If I understand correctly, fsync will call to log entire inode in
> the log tree. Does this mean that the data extents are also logged
> into
On Sun, Sep 29, 2013 at 01:46:23AM +0200, Aastha Mehta wrote:
> I am using linux kernel 3.1.10-1.16, just to let you know.
Not that it invalidates the questions below, but that's a really
old kernel. You should update to something recent (3.11, or 3.12-rc2)
as soon as possible. There are major
I am using linux kernel 3.1.10-1.16, just to let you know.
Thanks
On 29 September 2013 01:35, Aastha Mehta wrote:
> Hi,
>
> I have few questions regarding logging triggered by calling fsync in BTRFS:
>
> 1. If I understand correctly, fsync will call to log entire inode in
> the log tree. Does th
Hi,
I have few questions regarding logging triggered by calling fsync in BTRFS:
1. If I understand correctly, fsync will call to log entire inode in
the log tree. Does this mean that the data extents are also logged
into the log tree? Are they copied into the log tree, or just
referenced? Are the
On 28/09/13 20:26, Martin wrote:
> ... btrfsck bombs out with LOTs of errors...
>
> How best to recover from this?
>
> (This is a 'backup' disk so not 'critical' but it would be nice to avoid
> rewriting about 1.5TB of data over the network...)
>
>
> Is there an obvious sequence/recipe to foll
Chris,
All agreed. Further comment inlined:
(Should have mentioned more prominently that the hardware problem has
been worked-around by limiting the sata to 3Gbit/s on bootup.)
On 28/09/13 21:51, Chris Murphy wrote:
>
> On Sep 28, 2013, at 1:26 PM, Martin wrote:
>
>> Writing data via rsync a
On Sep 28, 2013, at 1:26 PM, Martin wrote:
> Writing data via rsync at the 6Gbit/s sata rate caused
> IO errors for just THREE sectors...
>
> Yet btrfsck bombs out with LOTs of errors…
Any fs will bomb out on write errors.
> How best to recover from this?
Why you're getting I/O errors at SAT
Hi,
I discovered one minor bug in BTRFS filesystem. I made nagios check
for btrfs which reads device statistics for all devices in mounted
btrfs filesystem, calling btrfs dev stats /btrfs.
But there is one problem ... it's output looks like this:
[/dev/sda].corruption_errs 0
..
...
[/dev/sdt].ge
This may be of interest for the fail cause aswel as how to recover...
I have a known good 2TB (4kByte physical sectors) HDD that supports
sata3 (6Gbit/s). Writing data via rsync at the 6Gbit/s sata rate caused
IO errors for just THREE sectors...
Yet btrfsck bombs out with LOTs of errors...
How
On 09/28/2013 05:29 AM, Chris Mason wrote:
Quoting Saul Wold (2013-09-19 14:19:34)
Hi there,
I am attempting to build a rootfs image from an existing rootfs
directory tree. I am using the 0.20 @ 194aa4a of Chris's git repo.
The couple problem I saw was that the target image file needed to exi
On 09/28/2013 03:10 AM, Zach Brown wrote:
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index de246ab..0f36cde 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -809,6 +809,7 @@ static int cmd_subvol_show(int argc, char **argv)
int fd = -1, mntfd = -1;
int ret = 1;
On 09/28/2013 02:32 AM, Zach Brown wrote:
@@ -49,14 +50,17 @@ static int cmd_add_dev(int argc, char **argv)
int i, fdmnt, ret=0, e;
DIR *dirstream = NULL;
int discard = 1;
+ int force = 0;
+ char estr[100];
+ res = test_dev_for_mkfs(argv[
Quoting Saul Wold (2013-09-19 14:19:34)
> Hi there,
>
> I am attempting to build a rootfs image from an existing rootfs
> directory tree. I am using the 0.20 @ 194aa4a of Chris's git repo.
>
> The couple problem I saw was that the target image file needed to exist,
> although I think I can pat
19 matches
Mail list logo
