Hi Duncan,
thank you for your detailed explanations!
Am 23.08.2014 07:27, schrieb Duncan:
btrfs-show-super is your tool for inspecting the superblocks. See the
manpage for the details.
Then use btrfs rescue super-recover to overwrite the bad superblock with
one that checks out as good (csum m
Florian Gamböck posted on Sat, 23 Aug 2014 10:38:47 +0200 as excerpted:
> Am 23.08.2014 07:27, schrieb Duncan:
>> btrfs-show-super is your tool for inspecting the superblocks. [...]
>> Then use btrfs rescue super-recover
> Yes, show-super told me, that the first super block did "NOT MATCH", but
On Sat, Aug 23, 2014 at 02:45:25PM +0900, Naohiro Aota wrote:
> On Sat, Aug 23, 2014 at 12:10 PM, Marc MERLIN wrote:
> > On Sat, Aug 23, 2014 at 02:52:16AM +, Duncan wrote:
> >> > For mysql, I got:
> >> > InnoDB: Page directory corruption:
> >> > infimum not pointed to 140708 11:53:58
> >> > I
On Sat, Aug 23, 2014 at 05:56:28AM +, Duncan wrote:
> Of course that begs the question of whether it was a normal COW file or
> if you had it NOCOW. Setting it NOCOW (of course doing the correct set
I had it at the default of COW, both chrome and mysql.
Marc
--
"A mouse is a device used t
On Sat, 23 Aug 2014 05:32:49 -0700, Marc MERLIN wrote:
> [snip]
> Thanks for that data point, so that rules out discard and SSDs.
>
> Given that, it sounds like btrfs may still have a bug where everything
> does not get to disk in the right order before the system stops.
A popular candidate for
Am 23.08.2014 11:34, schrieb Duncan:
Afterwards, as I said, none of the partitions were recognized anymore. Not even
btrfs recognized the third partition.
That is strange. Was the partition table still recognized? Had you used
mbr or gpt partitioning (I'm presuming the pi handles them, of cou
Hello,
I'm using archinux with btrfs as root filesystem, kernel 3.15.2, btrfs 3.14.2.
System was working fine for more than year, but suddenly
after large pacman update filesystem came to
unrecoverable error (remounted root ro).
I've decided to reboot, and after that btrfs failed to mount:
[ 16
On Sat, Aug 23, 2014 at 09:34:10AM +, Duncan wrote:
> Florian Gamböck posted on Sat, 23 Aug 2014 10:38:47 +0200 as excerpted:
>
> > Am 23.08.2014 07:27, schrieb Duncan:
> >> btrfs-show-super is your tool for inspecting the superblocks. [...]
> >> Then use btrfs rescue super-recover
>
> > Yes
This came from trying to convert a ~1.8T ext4 filesystem with btrfs-progs
master (24cf4d8c3ee924b474f68514e0167cc2e602a48d) on Debian. e2fsck -f
reports no errors on the source filesystem.
I've done several ext4 conversions before this one, so I'm pretty sure
the tool works most of the time. ;)
On Thu, Aug 21, 2014 at 1:07 PM, Naohiro Aota wrote:
> free_some_buffer() should not free dirty extent buffers. They should be
> left for later commit.
>
> Signed-off-by: Naohiro Aota
> ---
> extent_io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/extent_io.c b/exten
Zygo Blaxell posted on Sat, 23 Aug 2014 12:38:05 -0400 as excerpted:
> Consumer SD cards are /terrible/ storage devices. Always back up all
> data written to an SD card as soon as possible after writing it, and
> develop a process to restore the backup to a new SD card conveniently
> when--not if
Nikolay Shtabel posted on Sat, 23 Aug 2014 16:39:48 + as excerpted:
> After all, the last step is to use btrfs restore:
>
> btrfs restore -iv /dev/sdc2 /mnt/restore/
> Check tree block failed, want=471748608, have=0
> Check tree block failed, want=471748608, have=0
> read block failed check_
On Aug 23, 2014, at 6:56 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Zygo Blaxell posted on Sat, 23 Aug 2014 12:38:05 -0400 as excerpted:
>
>> Consumer SD cards are /terrible/ storage devices. Always back up all
>> data written to an SD card as soon as possible after writing it, and
>> develop a
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36293.html
says ButterSink will detect errors with backups. Anyone else except
the author tried this?
I'd like to know if any experienced person (other than the author,
with all due respect) has tried this backup utility and would like
th
It looks like this intended to be 64-bit arithmetic, but it's actually
performed as 32-bit. Fix that. (Note that 'increment' was being
initialized twice, so this patch removes one of those.)
Caught by Coverity Scan (CID 1201422).
Signed-off-by: Brian Norris
---
Untested
fs/btrfs/scrub.c | 12
On Sun, Aug 24, 2014 at 01:21:17AM +, Duncan wrote:
> It used to be common courtesy to read a couple weeks of the the backgroup/
> backlist before posting questions as they might be answered already. I
> guess it isn't so these days...
This is not scalable. There shouldn't be any recovery wi
16 matches
Mail list logo
