Is it expected that running btrfsck more than once will keep reporting errors?
Below is the end of a btrfsck output when run the second time.
backpointer mismatch on [111942471680 32768]
owner ref check failed [111942471680 32768]
ref mismatch on [111942504448 40960] extent item 1, found 0
Incorr
On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker wrote:
> Is it expected that running btrfsck more than once will keep reporting errors?
Without options, btrfsck does not write to the disk.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord.
On Sat, Mar 16, 2013 at 06:24:47AM -0600, cwillu wrote:
> On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker wrote:
> > Is it expected that running btrfsck more than once will keep reporting
> > errors?
>
> Without options, btrfsck does not write to the disk.
Ah, that explains why I never got i
On Sat, 16 Mar 2013, cwillu wrote:
> On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker wrote:
> > Is it expected that running btrfsck more than once will keep reporting
> > errors?
>
> Without options, btrfsck does not write to the disk.
The man page for the version in Debian doesn't document any
Eric Sandeen wrote:
>>
>> It did not put mkfs.btrfs in /sbin. This did however, validate all the
>> error paths ;).
> Heh ;)
> Well, mixing & matching upstream installs from source w/ rpm-packaged
> binaries is usually asking for trouble.
> I don't think it's a bug, just bad administrative p
On Sat, Mar 16, 2013 at 6:46 AM, Russell Coker wrote:
> On Sat, 16 Mar 2013, cwillu wrote:
>> On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker wrote:
>> > Is it expected that running btrfsck more than once will keep reporting
>> > errors?
>>
>> Without options, btrfsck does not write to the disk.
On Sat, Mar 16, 2013 at 6:44 AM, Marc MERLIN wrote:
> On Sat, Mar 16, 2013 at 06:24:47AM -0600, cwillu wrote:
>> On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker wrote:
>> > Is it expected that running btrfsck more than once will keep reporting
>> > errors?
>>
>> Without options, btrfsck does not
Quoting Liu Bo (2013-03-15 10:46:39)
> Users report that an extent map's list is still linked when it's actually
> going to be freed from cache.
>
> The story is that
>
> a) when we're going to drop an extent map and may split this large one into
> smaller ems, and if this large one is flagged as
Am Freitag, 8. März 2013 schrieb Frédéric COIFFIER:
> Hi,
Hi Frédéric,
> I'm using a Linux 3.7.6 (Gentoo Linux) with btrfs-progs-0.20_rc1_p56 and
> since few days, I have some uncorrectable errors :
>
> # btrfs scrub status /
> scrub status for 6b6ea99b-edee-498d-bf07-f3a3f1cba2f3
> scr
Am Freitag, 8. März 2013 schrieb Frédéric COIFFIER:
> Today, I can't remove the file (and I can't delete its directory),
> updatedb runs during hours when it tries to read this file. So, what is
> the best way to recover these errors (as I think that some files are
> definitely lost) ? I would like
Hi David,
On Thu, Mar 7, 2013 at 1:55 PM, David Sterba wrote:
> On Wed, Mar 06, 2013 at 10:12:11PM -0500, Chris Mason wrote:
>> > > Also, I want to ask, hope this is not inappropriate. Do you also agree
>> > > with Josef, that it's ok for BTRFS_IOC_SNAP_DESTROY not to commit the
>> > > transactio
On Tue, Mar 12, 2013 at 5:13 PM, David Sterba wrote:
> Each time pick one dead root from the list and let the caller know if
> it's needed to continue. This should improve responsiveness during
> umount and balance which at some point waits for cleaning all currently
> queued dead roots.
>
> A new
Share the exactly same code of stopping workers.
Signed-off-by: Liu Bo
---
fs/btrfs/disk-io.c | 55 +--
1 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 7d84651..06fa2ce 100644
--- a/f
13 matches
Mail list logo
