Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

On Wed, Jul 6, 2016 at 8:24 PM, Tomasz Kusmierz wrote: > you are throwing a lot of useful data, maybe diverting some of it into wiki ? > you know, us normal people might find it useful for making educated choice in > some future ? :) There is a wiki, and it's difficult

Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

On 7/6/16 8:35 AM, Holger Hoffstätte wrote: > On 07/06/16 14:25, Wang Shilong wrote: ... >> After patch, it will look like: >>Total Exclusive Set shared Filename >> skipping not btrfs dir/file: boot >> skipping not btrfs dir/file: dev >> skipping not btrfs dir/file: proc >> skipping not

Re: [PATCH 2/2] btrfs: fix false ENOSPC for btrfs_fallocate()

hello, On 07/06/2016 08:27 PM, Holger Hoffstätte wrote: On 07/06/16 12:37, Wang Xiaoguang wrote: Below test scripts can reproduce this false ENOSPC: #!/bin/bash dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128 dev=$(losetup --show -f fs.img) mkfs.btrfs -f

Re: [PATCH 1/2] btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster()

hello, On 07/07/2016 03:54 AM, Liu Bo wrote: On Wed, Jul 06, 2016 at 06:37:52PM +0800, Wang Xiaoguang wrote: In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses wrong file offset for reloc_inode, it uses cluster->start and cluster->end, which indeed are extent's bytenr. The

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

> On 7 Jul 2016, at 02:46, Chris Murphy wrote: > Chaps, I didn’t wanted this to spring up as a performance of btrfs argument, BUT you are throwing a lot of useful data, maybe diverting some of it into wiki ? you know, us normal people might find it useful for

[PATCH v1] btrfs: Avoid reading out unnecessary extent tree blocks when mounting

Btrfs_read_block_groups() function is the most time consuming function if the fs is large and filled with small extents. For a btrfs filled with 100,000,000 16K sized files, mount the fs takes about 10 seconds. While ftrace shows that, btrfs_read_block_groups() takes about 9 seconds, taking up

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

On Wed, Jul 6, 2016 at 5:22 PM, Kai Krakow wrote: > The current implementation of RAID0 in btrfs is probably not very > optimized. RAID0 is a special case anyways: Stripes have a defined > width - I'm not sure what it is for btrfs, probably it's per chunk, so > it's 1GB,

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

Am Thu, 7 Jul 2016 00:51:16 +0100 schrieb Tomasz Kusmierz : > > On 7 Jul 2016, at 00:22, Kai Krakow wrote: > > > > Am Wed, 6 Jul 2016 13:20:15 +0100 > > schrieb Tomasz Kusmierz : > > > >> When I think of it, I did move

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

> On 7 Jul 2016, at 00:22, Kai Krakow wrote: > > Am Wed, 6 Jul 2016 13:20:15 +0100 > schrieb Tomasz Kusmierz : > >> When I think of it, I did move this folder first when filesystem was >> RAID 1 (or not even RAID at all) and then it was upgraded to

Re: [PATCH 19/20] xfs: run xfs_repair at the end of each test

On Thu, Jul 07, 2016 at 09:13:40AM +1000, Dave Chinner wrote: > On Mon, Jul 04, 2016 at 09:11:34PM -0700, Darrick J. Wong wrote: > > On Tue, Jul 05, 2016 at 11:56:17AM +0800, Eryu Guan wrote: > > > On Thu, Jun 16, 2016 at 06:48:01PM -0700, Darrick J. Wong wrote: > > > > Run xfs_repair twice at the

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

Am Wed, 6 Jul 2016 13:20:15 +0100 schrieb Tomasz Kusmierz : > When I think of it, I did move this folder first when filesystem was > RAID 1 (or not even RAID at all) and then it was upgraded to RAID 1 > then RAID 10. Was there a faulty balance around August 2014 ? Please >

Re: [PATCH 19/20] xfs: run xfs_repair at the end of each test

On Mon, Jul 04, 2016 at 09:11:34PM -0700, Darrick J. Wong wrote: > On Tue, Jul 05, 2016 at 11:56:17AM +0800, Eryu Guan wrote: > > On Thu, Jun 16, 2016 at 06:48:01PM -0700, Darrick J. Wong wrote: > > > Run xfs_repair twice at the end of each test -- once to rebuild > > > the btree indices, and

Re: raid1 has failing disks, but smart is clear

> On 6 Jul 2016, at 23:14, Corey Coughlin wrote: > > Hi all, >Hoping you all can help, have a strange problem, think I know what's going > on, but could use some verification. I set up a raid1 type btrfs filesystem > on an Ubuntu 16.04 system, here's what it

Re: [PATCH v6 00/20] xfstests: minor fixes for the reflink/dedupe tests

On Tue, Jul 05, 2016 at 12:31:30PM +0800, Eryu Guan wrote: > Hi Darrick, > > On Thu, Jun 16, 2016 at 06:46:02PM -0700, Darrick J. Wong wrote: > > Hi all, > > > > This is the sixth revision of a patchset that adds to xfstests > > support for testing reverse-mappings of physical blocks to file and

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

> On 6 Jul 2016, at 22:41, Henk Slager wrote: > > On Wed, Jul 6, 2016 at 2:20 PM, Tomasz Kusmierz > wrote: >> >>> On 6 Jul 2016, at 02:25, Henk Slager wrote: >>> >>> On Wed, Jul 6, 2016 at 2:32 AM, Tomasz Kusmierz

raid1 has failing disks, but smart is clear

Hi all, Hoping you all can help, have a strange problem, think I know what's going on, but could use some verification. I set up a raid1 type btrfs filesystem on an Ubuntu 16.04 system, here's what it looks like: btrfs fi show Label: none uuid: 597ee185-36ac-4b68-8961-d4adc13f95d4

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

On Wed, Jul 6, 2016 at 2:20 PM, Tomasz Kusmierz wrote: > >> On 6 Jul 2016, at 02:25, Henk Slager wrote: >> >> On Wed, Jul 6, 2016 at 2:32 AM, Tomasz Kusmierz >> wrote: >>> >>> On 6 Jul 2016, at 00:30, Henk Slager

Re: Adventures in btrfs raid5 disk recovery

On Wed, Jul 6, 2016 at 1:15 PM, Austin S. Hemmelgarn wrote: > On 2016-07-06 14:45, Chris Murphy wrote: >> I think it's statistically 0 people changing this from default. It's >> people with drives that have no SCT ERC support, used in raid1+, who >> happen to stumble upon

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 1:17 PM, Austin S. Hemmelgarn wrote: > In bash or most other POSIX compliant shells, you can run this: > echo $? > to get the return code of the previous command. > > In your case though, it may be reporting the FS ready because it had already > seen

Re: [PATCH 1/2] btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster()

On Wed, Jul 06, 2016 at 06:37:52PM +0800, Wang Xiaoguang wrote: > In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses > wrong file offset for reloc_inode, it uses cluster->start and cluster->end, > which indeed are extent's bytenr. The correct value should be >

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 14:23, Chris Murphy wrote: On Wed, Jul 6, 2016 at 12:04 PM, Austin S. Hemmelgarn wrote: On 2016-07-06 13:19, Chris Murphy wrote: On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote: 3) can we query btrfs whether it is mountable

Re: Adventures in btrfs raid5 disk recovery

On 2016-07-06 14:45, Chris Murphy wrote: On Wed, Jul 6, 2016 at 11:18 AM, Austin S. Hemmelgarn wrote: On 2016-07-06 12:43, Chris Murphy wrote: So does it make sense to just set the default to 180? Or is there a smarter way to do this? I don't know. Just thinking

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 12:24 PM, Andrei Borzenkov wrote: > On Wed, Jul 6, 2016 at 8:19 PM, Chris Murphy wrote: >> >> I'm mainly concerned with rootfs. And I'm mainly concerned with a very >> simple 2 disk raid1. With a simple user opt in using >>

Re: Adventures in btrfs raid5 disk recovery

On Wed, Jul 6, 2016 at 11:18 AM, Austin S. Hemmelgarn wrote: > On 2016-07-06 12:43, Chris Murphy wrote: >> So does it make sense to just set the default to 180? Or is there a >> smarter way to do this? I don't know. > > Just thinking about this: > 1. People who are setting

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 9:23 PM, Chris Murphy wrote: >>> [root@f24s ~]# btrfs fi show >>> warning, device 2 is missing >>> Label: none uuid: 96240fd9-ea76-47e7-8cf4-05d3570ccfd7 >>> Total devices 3 FS bytes used 2.26GiB >>> devid3 size 50.00GiB used 3.01GiB

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 8:19 PM, Chris Murphy wrote: > > I'm mainly concerned with rootfs. And I'm mainly concerned with a very > simple 2 disk raid1. With a simple user opt in using > rootflags=degraded, it should be possible to boot the system. Right > now it's not

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 12:04 PM, Austin S. Hemmelgarn wrote: > On 2016-07-06 13:19, Chris Murphy wrote: >> >> On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov >> wrote: >>> >>> 3) can we query btrfs whether it is mountable in degraded mode? >>>

Re: Unable to mount degraded RAID5

On Wed, Jul 6, 2016 at 11:12 AM, Gonzalo Gomez-Arrue Azpiazu wrote: > Hello, > > I had a RAID5 with 3 disks and one failed; now the filesystem cannot be > mounted. > > None of the recommendations that I found seem to work. The situation > seems to be similar to this one: >

Re: Unable to mount degraded RAID5

On Wed, Jul 6, 2016 at 11:50 AM, Tomáš Hrdina wrote: > sudo mount -o ro /dev/sdc /shares > mount: wrong fs type, bad option, bad superblock on /dev/sdc, >missing codepage or helper program, or other error > >In some cases useful info is found in syslog - try

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 13:19, Chris Murphy wrote: On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote: 3) can we query btrfs whether it is mountable in degraded mode? according to documentation, "btrfs device ready" (which udev builtin follows) checks "if it has ALL of it’s

Re: Unable to mount degraded RAID5

sudo mount -o ro /dev/sdc /shares mount: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. sudo mount -o ro,recovery /dev/sdc /shares mount: wrong

Re: Out of space error even though there's 100 GB unused?

On Wed, Jul 6, 2016 at 3:55 AM, Stanislaw Kaminski wrote: > Device unallocated: 97.89GiB There should be no problem creating any type of block group from this much space. It's a bug. I would try regression testing. Kernel 4.5.7 has some changes that may

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

> On Jul 6, 2016, at 10:33 AM, Joerg Schilling > wrote: > > "Austin S. Hemmelgarn" wrote: > >> On 2016-07-06 11:22, Joerg Schilling wrote: >>> >>> >>> You are mistaken. >>> >>> stat /proc/$$/as >>> File: `/proc/6518/as' >>>

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote: > On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: >> I started a systemd-devel@ thread since that's where most udev stuff >> gets talked about. >> >>

Re: Adventures in btrfs raid5 disk recovery

On 2016-07-06 12:43, Chris Murphy wrote: On Wed, Jul 6, 2016 at 5:51 AM, Austin S. Hemmelgarn wrote: On 2016-07-05 19:05, Chris Murphy wrote: Related: http://www.spinics.net/lists/raid/msg52880.html Looks like there is some traction to figuring out what to do about

Fwd: Unable to mount degraded RAID5

Hello, I had a RAID5 with 3 disks and one failed; now the filesystem cannot be mounted. None of the recommendations that I found seem to work. The situation seems to be similar to this one: http://www.spinics.net/lists/linux-btrfs/msg56825.html Any suggestion on what to try next? Thanks a lot

Re: Adventures in btrfs raid5 disk recovery

On Wed, Jul 6, 2016 at 5:51 AM, Austin S. Hemmelgarn wrote: > On 2016-07-05 19:05, Chris Murphy wrote: >> >> Related: >> http://www.spinics.net/lists/raid/msg52880.html >> >> Looks like there is some traction to figuring out what to do about >> this, whether it's a udev rule

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

"Austin S. Hemmelgarn" wrote: > On 2016-07-06 11:22, Joerg Schilling wrote: > > "Austin S. Hemmelgarn" wrote: > > > >>> It should be obvious that a file that offers content also has allocated > >>> blocks. > >> What you mean then is that POSIX

Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

On Wed, Jul 06, 2016 at 05:42:33PM +0200, Holger Hoffstätte wrote: > On 07/06/16 17:20, Hugo Mills wrote: > > On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote: > >> On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte > >> wrote: > >>> On 07/06/16 14:25,

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 2016-07-06 12:05, Austin S. Hemmelgarn wrote: On 2016-07-06 11:22, Joerg Schilling wrote: "Austin S. Hemmelgarn" wrote: It should be obvious that a file that offers content also has allocated blocks. What you mean then is that POSIX _implies_ that this is the case,

Re: Unable to mount degraded RAID5

On Wed, Jul 6, 2016 at 2:07 AM, Tomáš Hrdina wrote: > Now with 3 disks: > > sudo btrfs check /dev/sda > parent transid verify failed on 7008807157760 wanted 70175 found 70133 > parent transid verify failed on 7008807157760 wanted 70175 found 70133 > checksum verify failed on

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 2016-07-06 11:22, Joerg Schilling wrote: "Austin S. Hemmelgarn" wrote: It should be obvious that a file that offers content also has allocated blocks. What you mean then is that POSIX _implies_ that this is the case, but does not say whether or not it is required.

Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

On 07/06/16 17:20, Hugo Mills wrote: > On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote: >> On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte >> wrote: >>> On 07/06/16 14:25, Wang Shilong wrote: 'btrfs file du' is a very useful tool to watch my

Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte wrote: > On 07/06/16 14:25, Wang Shilong wrote: >> 'btrfs file du' is a very useful tool to watch my system >> file usage with snapshot aware. >> >> when trying to run following commands: >> [root@localhost

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

"Austin S. Hemmelgarn" wrote: > > It should be obvious that a file that offers content also has allocated > > blocks. > What you mean then is that POSIX _implies_ that this is the case, but > does not say whether or not it is required. There are all kinds of >

Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote: > On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte > wrote: > > On 07/06/16 14:25, Wang Shilong wrote: > >> 'btrfs file du' is a very useful tool to watch my system > >> file usage with snapshot aware.

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 2016-07-06 10:53, Joerg Schilling wrote: Antonio Diaz Diaz wrote: Joerg Schilling wrote: POSIX requires st_blocks to be != 0 in case that the file contains data. Please, could you provide a reference? I can't find such requirement at

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 07/06/2016 05:09 PM, Joerg Schilling wrote: you concur that a delayed assignment of the "correct" value for st_blocks while the contend of the file does not change is not permitted. I'm not sure I agree even with that. A file system may undergo garbage collection and compaction, for

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

Paul Eggert wrote: > On 07/06/2016 04:53 PM, Joerg Schilling wrote: > > Antonio Diaz Diaz wrote: > > > >> >Joerg Schilling wrote: > >>> > >POSIX requires st_blocks to be != 0 in case that the file contains > >>> > >data. > >> > > >> >Please, could you

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 07/06/2016 04:53 PM, Joerg Schilling wrote: Antonio Diaz Diaz wrote: >Joerg Schilling wrote: > >POSIX requires st_blocks to be != 0 in case that the file contains data. > >Please, could you provide a reference? I can't find such requirement at

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

Antonio Diaz Diaz wrote: > Joerg Schilling wrote: > > POSIX requires st_blocks to be != 0 in case that the file contains data. > > Please, could you provide a reference? I can't find such requirement at > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

Joerg Schilling wrote: POSIX requires st_blocks to be != 0 in case that the file contains data. Please, could you provide a reference? I can't find such requirement at http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html Thanks. Antonio. -- To unsubscribe from this

Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

On 07/06/16 14:25, Wang Shilong wrote: > 'btrfs file du' is a very useful tool to watch my system > file usage with snapshot aware. > > when trying to run following commands: > [root@localhost btrfs-progs]# btrfs file du / > Total Exclusive Set shared Filename > ERROR: Failed to lookup

[PATCH] btrfs-progs: du: fix to skip not btrfs dir/file

'btrfs file du' is a very useful tool to watch my system file usage with snapshot aware. when trying to run following commands: [root@localhost btrfs-progs]# btrfs file du / Total Exclusive Set shared Filename ERROR: Failed to lookup root id - Inappropriate ioctl for device ERROR: cannot

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 06, 2016 at 02:55:37PM +0300, Andrei Borzenkov wrote: > On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn > wrote: > > On 2016-07-06 05:51, Andrei Borzenkov wrote: > >> > >> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy > >> wrote: >

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 08:39, Andrei Borzenkov wrote: Отправлено с iPhone 6 июля 2016 г., в 15:14, Austin S. Hemmelgarn написал(а): On 2016-07-06 07:55, Andrei Borzenkov wrote: On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn wrote: On 2016-07-06

Re: 64-btrfs.rules and degraded boot

Отправлено с iPhone > 6 июля 2016 г., в 15:14, Austin S. Hemmelgarn > написал(а): > >> On 2016-07-06 07:55, Andrei Borzenkov wrote: >> On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn >> wrote: >>> On 2016-07-06 05:51, Andrei Borzenkov wrote:

Re: [PATCH 2/2] btrfs: fix false ENOSPC for btrfs_fallocate()

On 07/06/16 12:37, Wang Xiaoguang wrote: > Below test scripts can reproduce this false ENOSPC: > #!/bin/bash > dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128 > dev=$(losetup --show -f fs.img) > mkfs.btrfs -f -M $dev > mkdir /tmp/mntpoint > mount

Re: btrfs RAID 10 truncates files over 2G to 4096 bytes.

> On 6 Jul 2016, at 02:25, Henk Slager wrote: > > On Wed, Jul 6, 2016 at 2:32 AM, Tomasz Kusmierz > wrote: >> >> On 6 Jul 2016, at 00:30, Henk Slager wrote: >> >> On Mon, Jul 4, 2016 at 11:28 PM, Tomasz Kusmierz

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 07:55, Andrei Borzenkov wrote: On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn wrote: On 2016-07-06 05:51, Andrei Borzenkov wrote: On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: I started a systemd-devel@ thread since

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn wrote: > On 2016-07-06 05:51, Andrei Borzenkov wrote: >> >> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy >> wrote: >>> >>> I started a systemd-devel@ thread since that's where most udev stuff >>>

Re: Adventures in btrfs raid5 disk recovery

On 2016-07-05 19:05, Chris Murphy wrote: Related: http://www.spinics.net/lists/raid/msg52880.html Looks like there is some traction to figuring out what to do about this, whether it's a udev rule or something that happens in the kernel itself. Pretty much the only hardware setup unaffected by

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

"Austin S. Hemmelgarn" wrote: > > A broken filesystem is a broken filesystem. > > > > If you try to change gtar to work around a specific problem, it may fail in > > other situations. > The problem with this is that tar is assuming things that are not > guaranteed to be

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 05:51, Andrei Borzenkov wrote: On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: I started a systemd-devel@ thread since that's where most udev stuff gets talked about. https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 2016-07-05 05:28, Joerg Schilling wrote: Andreas Dilger wrote: I think in addition to fixing btrfs (because it needs to work with existing tar/rsync/etc. tools) it makes sense to *also* fix the heuristics of tar to handle this situation more robustly. One option is if

Re: Out of space error even though there's 100 GB unused?

Hi Hugo, I agree that it seems to be a bug, and I'll be glad to help nail that down - if only because I have no other drive to move the data to :-) As for your suggestion - no change: [root@archb3 stan]# mount | grep home /dev/sda4 on /home type btrfs

[PATCH 2/2] btrfs: fix false ENOSPC for btrfs_fallocate()

Below test scripts can reproduce this false ENOSPC: #!/bin/bash dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128 dev=$(losetup --show -f fs.img) mkfs.btrfs -f -M $dev mkdir /tmp/mntpoint mount /dev/loop0 /tmp/mntpoint cd mntpoint

[PATCH 1/2] btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster()

In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses wrong file offset for reloc_inode, it uses cluster->start and cluster->end, which indeed are extent's bytenr. The correct value should be cluster->[start|end] minus block group's start bytenr. start bytenr cluster->start |

Re: Out of space error even though there's 100 GB unused?

On Wed, Jul 06, 2016 at 11:55:42AM +0200, Stanislaw Kaminski wrote: > Hi, > I am fighting with this since at least Monday - see > https://superuser.com/questions/1096658/btrfs-out-of-space-even-though-there-should-be-10-left > > Here's the data: > # uname -a > Linux archb3 4.6.3-2-ARCH #1

Re: Out of space error even though there's 100 GB unused?

Hi Alex, Thank for having a look. "You're trying to resize a fs that is probably already fully using the block device it's on. I don't see anything incorrect happening here, but I might be missing something." This was just to show that I can't do this, I know that it is already utilizing the

Re: [PATCH 1/2] btrfs: fix fsfreeze hang caused by delayed iputs deal

hello, On 07/05/2016 01:35 AM, David Sterba wrote: On Wed, Jun 29, 2016 at 01:15:10PM +0800, Wang Xiaoguang wrote: When running fstests generic/068, sometimes we got below WARNING: xfs_io D 8800331dbb20 0 6697 6693 0x0080 8800331dbb20 88007acfc140

Re: [PATCH 2/2] btrfs: fix free space calculation in dump_space_info()

hello, On 07/05/2016 01:10 AM, David Sterba wrote: On Wed, Jun 29, 2016 at 01:12:16PM +0800, Wang Xiaoguang wrote: Can you please describe in more detail what is this patch fixing? In original dump_space_info(), free space info is calculated by info->total_bytes - info->bytes_used -

Out of space error even though there's 100 GB unused?

Hi, I am fighting with this since at least Monday - see https://superuser.com/questions/1096658/btrfs-out-of-space-even-though-there-should-be-10-left Here's the data: # uname -a Linux archb3 4.6.3-2-ARCH #1 PREEMPT Wed Jun 29 07:15:33 MDT 2016 armv5tel GNU/Linux # btrfs --version

Re: 64-btrfs.rules and degraded boot

On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: > I started a systemd-devel@ thread since that's where most udev stuff > gets talked about. > > https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html > Before discussing how to implement it in

Re: Unable to mount degraded RAID5

Now with 3 disks: sudo btrfs check /dev/sda parent transid verify failed on 7008807157760 wanted 70175 found 70133 parent transid verify failed on 7008807157760 wanted 70175 found 70133 checksum verify failed on 7008807157760 found F192848C wanted 1571393A checksum verify failed on 7008807157760