Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

On 2018年01月14日 18:13, Ilan Schwarts wrote: > both btrfs filesystems will have same fsid ? > > > On Sun, Jan 14, 2018 at 12:06 PM, Ilan Schwarts wrote: >> But both filesystems will have same fsid? >> >> On Jan 14, 2018 12:04, "Nikolay Borisov" wrote: >>>

Partionless Btrfs drives now return PTTYPE="PMBR"

I removed two partitionless Btrfs formatted drives from an Arch Linux based PC and installed them in another Linux based PC also running Arch. The drives are independent of one another, each containing its own Btrfs filesystem. Both machines are running recent kernels and the original host would

Re: Hanging after frequent use of systemd-nspawn --ephemeral

Qu Wenruo posted on Sun, 14 Jan 2018 10:27:40 +0800 as excerpted: > Despite of that, did that really hangs? > Qgroup dramatically increase overhead to delete a subvolume or balance > the fs. > Maybe it's just a little slow? Same question about the "hang" here. Note that btrfs is optimized to

Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

Hello btrfs developers/users, I was wondering regarding to fetching the correct fsid on btrfs from the context of a kernel module. if on suse11.3 kernel 3.0.101-0.47.71-default in order to get fsid, I do the following: convert inode struct to btrfs_inode struct (use btrfsInode = BTRFS_I(inode)),

Re: [PATCHSET v5] blk-mq: reimplement timeout handling

On Sun, Jan 14, 2018 at 11:12 PM, jianchao.wang wrote: > > > On 01/13/2018 05:19 AM, Bart Van Assche wrote: >> Sorry but I only retrieved the blk-mq debugfs several minutes after the hang >> started so I'm not sure the state information is relevant. Anyway, I have >>

Re: Limit on the number of btrfs snapshots?

Daniel E. Shub posted on Fri, 12 Jan 2018 16:38:30 -0500 as excerpted: > A couple of years ago I asked a question on the Unix and Linux Stack > Exchange about the limit on the number of BTRFS snapshots: > https://unix.stackexchange.com/q/140360/22724 > > Basically, I want to use something like

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

On 14.01.2018 12:02, Ilan Schwarts wrote: > First of all, Thanks for response ! > So if i have 2 btrfs file system on the same machine (not your > everyday scenario, i know) > Lets say a file is created on device A, the file gets inode number X > is it possible on device B to have inode number X

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

First of all, Thanks for response ! So if i have 2 btrfs file system on the same machine (not your everyday scenario, i know) Lets say a file is created on device A, the file gets inode number X is it possible on device B to have inode number X also ? or each device has its own Inode number range

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

both btrfs filesystems will have same fsid ? On Sun, Jan 14, 2018 at 12:06 PM, Ilan Schwarts wrote: > But both filesystems will have same fsid? > > On Jan 14, 2018 12:04, "Nikolay Borisov" wrote: >> >> >> >> On 14.01.2018 12:02, Ilan Schwarts wrote: >> >

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

On Sun, Jan 14, 2018 at 12:32:25PM +0200, Ilan Schwarts wrote: > Thank you for clarification. > Just 2 quick questions, > 1. Sub volumes - 2 sub volumes cannot have 2 same inode numbers ? Incorrect. You can have two subvolumes of the same filesystem, and you can have files with the same inode

Re: [PATCHSET v5] blk-mq: reimplement timeout handling

On 01/13/2018 05:19 AM, Bart Van Assche wrote: > Sorry but I only retrieved the blk-mq debugfs several minutes after the hang > started so I'm not sure the state information is relevant. Anyway, I have > attached > it to this e-mail. The most remarkable part is the following: > >

Re: invalid files names, btrfs check can't repair it

On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote: > Still needs more. (and maybe even more depending on the output) > > The original mode doesn't report error clear enough, so it would help if > --mode=lowmem can be used. > > # btrfs check --mode=lowmem /dev/sdb4 ~# btrfs check --mode=lowmem

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

On 2018年01月14日 18:32, Ilan Schwarts wrote: > Thank you for clarification. > Just 2 quick questions, > 1. Sub volumes - 2 sub volumes cannot have 2 same inode numbers ? They can. So to really locate an inode in btrfs, you need: fsid (locate the fs) -> subvolume id (locate subvolume) -> inode

Re: Hanging after frequent use of systemd-nspawn --ephemeral

On 2018年01月15日 04:17, Johannes Ernst wrote: >> On Jan 13, 2018, at 18:27, Qu Wenruo wrote: >> On 2018年01月14日 09:36, Johannes Ernst wrote: >>> Summary: frequent “hangs” of the system with dmesg saying: >>> >>> task systemd:9 blocked for more than 120 seconds. >>> [

Re: Hanging after frequent use of systemd-nspawn --ephemeral

> On Jan 13, 2018, at 18:27, Qu Wenruo wrote: > On 2018年01月14日 09:36, Johannes Ernst wrote: >> Summary: frequent “hangs” of the system with dmesg saying: >> >> task systemd:9 blocked for more than 120 seconds. >> [ 2948.928653] Tainted: G C O

Re: Hanging after frequent use of systemd-nspawn --ephemeral

> On Jan 13, 2018, at 18:27, Qu Wenruo wrote: > On 2018年01月14日 09:36, Johannes Ernst wrote: >> Summary: frequent “hangs” of the system with dmesg saying: >> >> task systemd:9 blocked for more than 120 seconds. >> [ 2948.928653] Tainted: G C O

Re: invalid files names, btrfs check can't repair it

On 2018年01月15日 00:38, Sebastian Andrzej Siewior wrote: > On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote: >> Still needs more. (and maybe even more depending on the output) >> >> The original mode doesn't report error clear enough, so it would help if >> --mode=lowmem can be used. >> >> # btrfs

Re: Hanging after frequent use of systemd-nspawn --ephemeral

On 2018年01月15日 08:58, Johannes Ernst wrote: >>> INFO: task systemd-journal:20876 blocked for more than 120 seconds. >>> [ 5037.962603] Tainted: G C O4.14.9-1-ARCH #1 >>> [ 5037.962609] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables >>> this message. >>> [

Re: Hanging after frequent use of systemd-nspawn --ephemeral

INFO: task systemd-journal:20876 blocked for more than 120 seconds. [ 5037.962603] Tainted: G C O4.14.9-1-ARCH #1 [ 5037.962609] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 5037.962616] systemd-journal D0 20876 20860

[PATCH] btrfs: Add chunk allocation ENOSPC debug message for enospc_debug mount option

Enospc_debug makes extent allocator to print more debug messages, however for chunk allocation, there is no debug message for enospc_debug at all. This patch will add message for the following parts of chunk allocator: 1) No rw device at all Quite rare, but at least output one message for

[PATCH] btrfs-progs: fsck: Continue check even if we find space cache problem

Space cache itself is not a fatal part of btrfs (especially for v1 space cache), and if we find something wrong it can be caused by other more serious problem. So continue to check more important trees even we found something wrong in free space cache. Signed-off-by: Qu Wenruo

Re: [PATCH] fstests: common/rc: fix device still mounted error with SCRATCH_DEV_POOL

On Fri, Jan 12, 2018 at 06:04:59PM -0700, Liu Bo wrote: > One of btrfs tests, btrfs/011, uses SCRATCH_DEV_POOL and puts a > non-SCRATCH_DEV > device as the first one when doing mkfs, and this makes > _require_scratch{_nocheck} fail to umount $SCRATCH_MNT since it checks mount > point with

Re: Hanging after frequent use of systemd-nspawn --ephemeral

>> INFO: task systemd-journal:20876 blocked for more than 120 seconds. >> [ 5037.962603] Tainted: G C O4.14.9-1-ARCH #1 >> [ 5037.962609] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables >> this message. >> [ 5037.962616] systemd-journal D0 20876 20860 0x0100

Re: Partionless Btrfs drives now return PTTYPE="PMBR"

On 2018年01月15日 00:36, evan d wrote: > I removed two partitionless Btrfs formatted drives from an Arch Linux > based PC and installed them in another Linux based PC also running > Arch. The drives are independent of one another, each containing its > own Btrfs filesystem. Both machines are

Re: Hanging after frequent use of systemd-nspawn --ephemeral

On 2018年01月15日 09:47, Johannes Ernst wrote: > INFO: task systemd-journal:20876 blocked for more than 120 seconds. > [ 5037.962603] Tainted: G C O4.14.9-1-ARCH #1 > [ 5037.962609] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. >

Re: invalid files names, btrfs check can't repair it

On Mon, Jan 15, 2018 at 09:26:27AM +0800, Qu Wenruo wrote: > > >On 2018年01月15日 00:38, Sebastian Andrzej Siewior wrote: >> On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote: >>> Still needs more. (and maybe even more depending on the output) >>> >>> The original mode doesn't report error clear

Re: invalid files names, btrfs check can't repair it

On 2018年01月15日 09:59, Lu Fengqi wrote: > On Mon, Jan 15, 2018 at 09:26:27AM +0800, Qu Wenruo wrote: >> >> >> On 2018年01月15日 00:38, Sebastian Andrzej Siewior wrote: >>> On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote: Still needs more. (and maybe even more depending on the output)

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

On 2018年01月14日 16:33, Ilan Schwarts wrote: > Hello btrfs developers/users, > > I was wondering regarding to fetching the correct fsid on btrfs from > the context of a kernel module. There are two IDs for btrfs. (in fact more, but you properly won't need the extra ids) FSID: Global one, one fs

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

On 2018年01月14日 16:33, Ilan Schwarts wrote: > Hello btrfs developers/users, > > I was wondering regarding to fetching the correct fsid on btrfs from > the context of a kernel module. There are two IDs for btrfs. (in fact more, but you properly won't need the extra ids) FSID: Global one, one fs

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

Thank you for clarification. Just 2 quick questions, 1. Sub volumes - 2 sub volumes cannot have 2 same inode numbers ? 2. Why fsInfo fsid return u8 and the traditional file system return dev_t, usually 32 integer ? On Sun, Jan 14, 2018 at 12:22 PM, Qu Wenruo wrote: > > >