Re: [PATCH 0/6] btrfs dax IO

2016-12-07 Thread Xin Zhou
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

Re: btrfs-find-root duration?

2016-12-10 Thread Xin Zhou
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

Re: Server hangs when mount BTRFS filesystem.

2016-12-15 Thread Xin Zhou
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

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

2016-12-13 Thread Xin Zhou
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  

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

2016-12-14 Thread Xin Zhou
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

Re: Help please: BTRFS fs crashed due to bad removal of USB drive, no help from recovery procedures

2016-12-17 Thread Xin Zhou
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: 

Re: OOM: Better, but still there on

2016-12-17 Thread Xin Zhou
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"

Re: [PATCH] btrfs: fix hole read corruption for compressed inline extents

2016-12-11 Thread Xin Zhou
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: 

Re: [markfasheh/duperemove] Why blocksize is limit to 1MB?

2016-12-31 Thread Xin Zhou
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: 

Re: [markfasheh/duperemove] Why blocksize is limit to 1MB?

2017-01-02 Thread Xin Zhou
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: &

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-20 Thread Xin Zhou
: 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

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-18 Thread Xin Zhou
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

Re: Help please: BTRFS fs crashed due to bad removal of USB drive, no help from recovery procedures

2016-12-19 Thread Xin Zhou
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

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-21 Thread Xin Zhou
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

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-23 Thread Xin Zhou
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

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-23 Thread Xin Zhou
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

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-26 Thread Xin Zhou
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.

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-25 Thread Xin Zhou
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

Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive

2016-12-26 Thread Xin Zhou
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

Re: btrfs_log2phys: cannot lookup extent mapping

2016-12-22 Thread Xin Zhou
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