If we use mount option "-o max_inline=sectorsize", say 4096, indeed
even for a fresh fs, say nodesize is 16k, we can not make the first
4k data completely inline, I found this conditon causing this issue:
!compressed_size && (actual_end & (root->sectorsize - 1)) == 0
If it retuns true, we'll not
hi,
On 10/11/2016 07:09 AM, Dave Chinner wrote:
On Mon, Oct 10, 2016 at 01:06:47PM +0800, Wang Xiaoguang wrote:
For btrfs, if compression is enabled, it may generate inline data for a
blocksize data range, this inline data is stored in fs tree, will not have
a individual extent, try to reflink
What do you get for
btrfs-find-root
btrfs rescue super-recover -v
It shouldn't matter which dev you pick, unless it face plants, then try another.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
hi,
On 10/11/2016 04:06 AM, Stefan Priebe - Profihost AG wrote:
Dear Wang,
Am 06.10.2016 um 05:04 schrieb Wang Xiaoguang:
Hi,
On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote:
Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang:
I found that compress sometime report ENOSPC error even in
Add a new test case to check if btrfs-convert copies common inode flags
like append(a), immutable(i).
Signed-off-by: Qu Wenruo
---
tests/convert-tests/009-common-inode-flags/test.sh | 34 ++
1 file changed, 34 insertions(+)
create mode 100755 tests/convert-tests/009-common-i
Before this patch, only 3 inode flags have readable string: NODATACOW,
NODATASUM, READONLY.
This patch will output all readable strings for remaining inode flags,
making debug-tree tool more handy.
Signed-off-by: Qu Wenruo
---
print-tree.c | 47 +++
1
Btrfs-progs header lacks quite a lot inode flags.
Copy them from kernel for later use.
Signed-off-by: Qu Wenruo
---
ctree.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/ctree.h b/ctree.h
index e0dd2e4..c76b1f1 100644
--- a/ctree.h
+++ b/ctree.h
@@ -1246,6 +1246,15 @@ struct btrfs
Before this patch, btrfs-convert never copy ext* inode flags to
corresponding btrfs inode flags.
This makes common flags like APPEND/SYNC/SYNCDIR/IMMUTABLE not copied to
btrfs inode.
This patch introduces ext2_convert_inode_flags() function to handle the
convert, so btrfs-convert can copy as many
Branch can be fetched from:
https://github.com/adam900710/btrfs-progs/tree/convert_inode_flags
Thanks for the report from Lakshmipathi.G, we exposed a bug that
btrfs-convert never copies common inode flags like SYNC/IMMUTABLE/APPEND.
The root cause is quite awkward, we didn't even have these flag
At 10/10/2016 11:50 PM, David Sterba wrote:
On Mon, Oct 10, 2016 at 11:11:19AM +0800, Qu Wenruo wrote:
Before this patch, only 3 inode flags have readable string: NODATACOW,
NODATASUM, READONLY.
This patch will output all readable strings for remaining inode flags,
making debug-tree tool more
On Mon, Oct 10, 2016 at 04:06:17PM +0800, Wang Xiaoguang wrote:
> When enabling btrfs compression, original codes can not fill fs
> correctly, fix this.
>
> Signed-off-by: Wang Xiaoguang
> ---
> V2: In common/, I did't find an existing function suitable for
> these 4 test cases to fill fs, so
On Mon, Oct 10, 2016 at 01:06:47PM +0800, Wang Xiaoguang wrote:
> For btrfs, if compression is enabled, it may generate inline data for a
> blocksize data range, this inline data is stored in fs tree, will not have
> a individual extent, try to reflink this data range at a not-zero offset
> will re
Hi liubo,
item 109 has a few strange chars in its name (and it's truncated):
1-x86_64.pkg.tar.xz 0x62 0x14 0x0a 0x0a
item 105 key (261 DIR_ITEM 54556048) itemoff 11723 itemsize 72
location key (606286 INODE_ITEM 0) type FILE
namelen 42 datalen 0 name:
p
On 09/02/2016 03:46 AM, Naohiro Aota wrote:
Currently, btrfs_relocate_chunk() is removing relocated BG by itself. But
the work can be done by btrfs_delete_unused_bgs() (and it's better since it
trim the BG). Let's dedupe the code.
While btrfs_delete_unused_bgs() is already hitting the relocated
On Mon, Oct 10, 2016 at 12:42 PM, Roman Mamedov wrote:
> On Mon, 10 Oct 2016 10:44:39 +0100
> Martin Dev wrote:
>
>> I work for system verification of SSDs and we've recently come up
>> against an issue with BTRFS on Ubuntu 16.04
>
>> This seems to be a recent change
>
> ...well, a change in what
On Mon, Oct 10, 2016 at 08:57:19PM +0200, a...@aron.ws wrote:
> Hi all,
>
> I've been using btrfs for a few months now, without any problems. During
> work, I've noticed segfaults, when accessing my root directory. As my home
> directory contents was readable, I've decided to reboot. That was the
On Mon, Oct 10, 2016 at 10:04 AM, Jason D. Michaelson
wrote:
> One of the disks had a write problem, unbeknownst to me, which caused the
> entire pool and its subvolumes to remount read only.
Can you be more specific about the write problem? What are the
messages from the logs about these write
Dear Wang,
Am 06.10.2016 um 05:04 schrieb Wang Xiaoguang:
> Hi,
>
> On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote:
>> Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang:
> I found that compress sometime report ENOSPC error even in 4.8-rc8,
> currently
I cannot confirm that as
Hi all,
I've been using btrfs for a few months now, without any problems.
During work, I've noticed segfaults, when accessing my root directory.
As my home directory contents was readable, I've decided to reboot. That
was the worst decision, as now I can't copy my data off the SSD. It
seems l
On Mon, 10 Oct 2016 10:44:39 +0100
Martin Dev wrote:
> I work for system verification of SSDs and we've recently come up
> against an issue with BTRFS on Ubuntu 16.04
> This seems to be a recent change
...well, a change in what?
If you really didn't change anything on your machines and the us
On Mon, Oct 10, 2016 at 04:55:03PM +0100, Al Viro wrote:
> > WARNING: CPU: 1 PID: 13581 at lib/iov_iter.c:327 sanity+0x102/0x150
> > CPU: 1 PID: 13581 Comm: trinity-c17 Not tainted 4.8.0-think+ #9
> > c9963ae8
> > b93e22d1
> >
> >
> >
On Mon, Oct 10, 2016 at 05:03:49PM +0800, Anand Jain wrote:
>
>
> On 10/10/16 13:06, Wang Xiaoguang wrote:
> >For btrfs, if compression is enabled, it may generate inline data for a
> >blocksize data range, this inline data is stored in fs tree, will not have
> >a individual extent, try to reflin
At some point in the last week, I had a 6-disk raid6 pool go south on me.
One of the disks had a write problem, unbeknownst to me, which caused the
entire pool and its subvolumes to remount read only.
When this problem occurred I was on debian jessie kernel 3.16.something.
Following list advice I
On Mon, Oct 10, 2016 at 11:11:19AM +0800, Qu Wenruo wrote:
> Before this patch, only 3 inode flags have readable string: NODATACOW,
> NODATASUM, READONLY.
>
> This patch will output all readable strings for remaining inode flags,
> making debug-tree tool more handy.
>
> Signed-off-by: Qu Wenruo
On Mon, Oct 10, 2016 at 09:11:22AM -0400, Dave Jones wrote:
> My compiler choked on that, but I fixed it up. The printk didn't
> trigger though..
>
> idx = 0, offset = 0
> curbuf = 0, nrbufs = 1, buffers = 16
> [b9a21100 ea00126019c0 0 4096]
> [ (null) ea0013746440 0 0]
>
On Sun, Oct 09, 2016 at 05:08:12PM +0200, Lakshmipathi.G wrote:
> Signed-off-by: Lakshmipathi.G
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Mon, Oct 10, 2016 at 02:04:55PM +0200, Lakshmipathi.G wrote:
> Signed-off-by: Lakshmipathi.G
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
After some investigation this seems to follow the discard flag set in fstab.
9 or so reproductions with discard on partition 2 fail
move discard flag to partition 1, then partition 1 fails.
Re-running our tests with no discard options set in fstab
On Mon, Oct 10, 2016 at 1:02 PM, Martin Dev wro
On 10/10/16 19:08, David Sterba wrote:
On Mon, Oct 10, 2016 at 06:54:08PM +0800, Anand Jain wrote:
On 10/10/16 17:21, Qu Wenruo wrote:
For multi-device btrfs, after UUID change we should info kernel, or new
fs can't be mounted due to false alert on missing devices.
Signed-off-by: Qu Wenruo
On Mon, Oct 10, 2016 at 04:43:57AM +0100, Al Viro wrote:
> Very interesting. Could you slap something like
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 0ce3411..1ef00e7 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -682,8 +682,9 @@ static void pipe_advance(struct iov_
Here is another trace, similar to the original issue, but I have a bit
more detail on this one and it is available as text which if nothing
else is more convenient so I'll go ahead and paste this. I don't
intend to keep pasting these unless I get something that looks
different.
I only posted the
On 2016-10-09 19:12, Charles Zeitler wrote:
Is there any advantage to using NAS drives
under RAID levels, as oppposed to regular
'desktop' drives for BTRFS?
Before I answer the question, it is worth explaining the differences
between the marketing terms 'desktop', 'enterprise', 'NAS', and 'vide
Signed-off-by: Lakshmipathi.G
---
btrfs-debugfs | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/btrfs-debugfs b/btrfs-debugfs
index 0a654a6..dfb8853 100755
--- a/btrfs-debugfs
+++ b/btrfs-debugfs
@@ -4,7 +4,7 @@
# LGPLv2 license
# Copyright Facebook 2014
-import sys
Additional BTRFS scrub logs
root@# btrfs scrub start -B /mnt/g/
scrub done for 554b0043-052f-48d1-986f-5a6154496d89
scrub started at Mon Oct 10 12:52:40 2016 and finished after 00:00:39
total bytes scrubbed: 20.03GiB with 46304 errors
error details: csum=46304
corrected errors:
On Mon, Oct 10, 2016 at 06:54:08PM +0800, Anand Jain wrote:
>
>
> On 10/10/16 17:21, Qu Wenruo wrote:
> > For multi-device btrfs, after UUID change we should info kernel, or new
> > fs can't be mounted due to false alert on missing devices.
> >
> > Signed-off-by: Qu Wenruo
> > ---
> > btrfstune
On 10/10/16 17:21, Qu Wenruo wrote:
For multi-device btrfs, after UUID change we should info kernel, or new
fs can't be mounted due to false alert on missing devices.
Signed-off-by: Qu Wenruo
---
btrfstune.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/btrfstune.c b/btrfstune
Hi,
another pre-release. The problem with ioctl on 32bit ARM that Justin reported
shows we have to be more careful with the changes to ioctl structures. The
build size checks are now optional (make D=bcheck to enable) and the patches to
add packing, alignment or alternate structures are left out.
Hey everyone,
I work for system verification of SSDs and we've recently come up
against an issue with BTRFS on Ubuntu 16.04. We have a framework which
follows the following steps:
Generate verifiable 10GB file with FIO on internal drive
Copy 10GB file to 2 target partitions on DUT (using "cp" com
For multi-device btrfs, after UUID change we should info kernel, or new
fs can't be mounted due to false alert on missing devices.
Signed-off-by: Qu Wenruo
---
btrfstune.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/btrfstune.c b/btrfstune.c
index 15dde90..23d06ce 100644
--- a/b
hi,
On 10/07/2016 09:16 PM, Josef Bacik wrote:
On 09/21/2016 02:59 AM, Wang Xiaoguang wrote:
In flush_space()->shrink_delalloc(), if can_overcommit() returns true,
though no bytes added to space_info, we still may satisfy some requests.
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/extent-tree.
Hi,
On 10/07/2016 09:24 PM, Josef Bacik wrote:
On 09/22/2016 05:25 AM, Wang Xiaoguang wrote:
Since commit b02441999efcc6152b87cd58e7970bb7843f76cf, we don't wait all
ordered extents, but I run into some enospc errors when doing large file
create and delete test, it's because shrink_delalloc() d
On 10/10/16 13:06, Wang Xiaoguang wrote:
For btrfs, if compression is enabled, it may generate inline data for a
blocksize data range, this inline data is stored in fs tree, will not have
a individual extent, try to reflink this data range at a not-zero offset
will return EOPNOTSUPP, so here we
When enabling btrfs compression, original codes can not fill fs
correctly, fix this.
Signed-off-by: Wang Xiaoguang
---
V2: In common/, I did't find an existing function suitable for
these 4 test cases to fill fs, so I still use _pwrite_byte() with
a big enough file length fo fill fs. Note
>From experience, for a video-archiv and backup-server its not a
problem to use desktop drives if you respect the following thinks:
1. Avoid stock "green"-drives; For example, use the WD Idle tool to
stop excessive load cycles for WD Green drives
2. Desktop drives didn't have time-limited error re
44 matches
Mail list logo