Hi Liu,
>From the patch, is the snapshot disabled by disabling the COW in the mounting
>path?
It seems the create_snapshot() in ioctl.c does not get changed.
I experienced some similar system but am a bit new to the brtfs code.
Thanks,
Xin
Subject: [PATCH 0/6] btrfs dax IOFrom: Liu Bo
Hi Markus,
Some file system automatically generates snapshot, and create a hidden folder
for recovery,
if the user accidently deletes some files.
It seems btrfs also has a autosnap feature,
so if this option has been enabled before deletion,
or the volume has been mannually generated
Hi Кравцов,
>From the log message, it seems dm-22 has been running out space, probably some
>checksum did not get committed to disk.
And when trying to repair, it reports checksum missing.
merge_reloc_roots:2426: errno=-28 No space left
Dec 15 00:05:47 OraCI2 kernel: BTRFS warning (device
Hi David,
It has GFP_NOFS flags, according to definition,
the issue might have happened during initial DISK/IO.
By the way, did you get a chance to dump the meminfo and run "top" before the
system hang?
It seems more info about the system running state needed to know the issue.
Thanks.
Xin
Hi,
The dirty data is in large amount, probably unable to commit to disk.
And this seems to happen when copying from 7200rpm to 5600rpm disks, according
to previous post.
Probably the I/Os are buffered and pending, unable to get finished in-time.
It might be helpful to know if this only happens
Hi Jari,
Similar with other file system, btrfs has copies of super blocks.
Try to run "man btrfs check", "man btrfs rescue" and related commands for more
details.
Regards,
Xin
Sent: Saturday, December 17, 2016 at 2:06 AM
From: "Jari Seppälä"
To:
Hi,
The system supposes to have special memory reservation for coredump and other
debug info when encountering panic,
the size seems configurable.
Thanks,
Xin
Sent: Saturday, December 17, 2016 at 6:44 AM
From: "Tetsuo Handa"
To: "Nils Holland"
Hi Zygo,
Since the corruption happens after I/O and checksum,
could it be possible to add some bug catcher code in code path for debug build,
to help narrowing down the issue?
Thanks,
Xin
Sent: Saturday, December 10, 2016 at 9:16 PM
From: "Zygo Blaxell"
To:
Hi,
In general, the larger the block / chunk size is, the less dedup can be
achieved.
1M is already a little bit too big in size.
Thanks,
Xin
Sent: Friday, December 30, 2016 at 12:28 PM
From: "Peter Becker"
To: linux-btrfs
Subject:
Hi,
Before doing that, probably one way to think about it could be,
what would be the probablitity of two 100M blocks generate the same hash and be
treated as identical.
Thanks,
Xin
Sent: Monday, January 02, 2017 at 4:32 AM
From: "Peter Becker" <floyd@gmail.com>
To: &
: Monday, December 19, 2016 at 10:55 AM
From: "Giuseppe Della Bianca" <b...@adria.it>
To: "Xin Zhou" <xin.z...@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system
during the snapshot receive
a concrete ex
Hi Giuseppe,
Would you like to tell some details about:
1. the XYZ snapshot was taken from which subvolume
2. where the base (initial) snapshot is stored
3. The 3 partitions receives the same snapshot, are they in the same btrfs
configuration and subvol structure?
Also, would you send the link
rom: "Jari Seppälä" <lihamakaroonilaati...@gmail.com>
To: linux-btrfs@vger.kernel.org
Cc: "Xin Zhou" <xin.z...@gmx.com>
Subject: Re: Help please: BTRFS fs crashed due to bad removal of USB drive, no
help from recovery procedures
Xin Zhou <xin.z...@gmx.com> kirj
rremedies.com>
To: No recipient address
Cc: "Giuseppe Della Bianca" <b...@adria.it>, "Xin Zhou" <xin.z...@gmx.com>,
"Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system
during the sn
the same
subvolume.
Is possible that the same subvolume is mounted several times (temporary mount
at the beginning, and unmount at the end, in my script).
Thanks for all.
P.S. Sorry for my bad English.
Gdb
In data mercoledì 21 dicembre 2016 23:14:44, Xin Zhou ha scritto:
> Hi,
> Racing con
onment.
Thanks,
Xin
Sent: Friday, December 23, 2016 at 9:48 AM
From: b...@adria.it
To: "Xin Zhou" <xin.z...@gmx.com>
Cc: "Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system
during the snapshot r
el.org
Subject: Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system
during the snapshot receive
Xin Zhou posted on Mon, 26 Dec 2016 03:36:09 +0100 as excerpted:
> One interesting thing to investigate might be the btrfs send / receive
> result, under a disruptive network environment.
SYSTEM] Corrupted and unrecoverable file system
during the snapshot receive
Xin Zhou posted on Sat, 24 Dec 2016 21:15:40 +0100 as excerpted:
> The code is relatively new to me, I did not see retry logic in stream
> handling, please correct me if I am wrong about this.
> So, I am not q
be in other
place.
Xin
Sent: Monday, December 26, 2016 at 3:04 AM
From: "Giuseppe Della Bianca" <b...@adria.it>
To: "Xin Zhou" <xin.z...@gmx.com>, "Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable
Hi,
If the change of disk format between versions is precisely documented,
it is plausible to create a utility to convert the old volume to new ones,
trigger the workflow, upgrade the kernel and boots up for mounting the new
volume.
Currently, the btrfs wiki shows partial content of the on-disk
20 matches
Mail list logo