At 05/24/2017 01:08 PM, Eryu Guan wrote:
On Wed, May 24, 2017 at 12:28:34PM +0800, Qu Wenruo wrote:
At 05/24/2017 12:24 PM, Eryu Guan wrote:
On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote:
At 05/23/2017 07:13 PM, Eryu Guan wrote:
On Tue, May 23, 2017 at 04:02:05PM +0800, Qu
On Wed, May 24, 2017 at 12:28:34PM +0800, Qu Wenruo wrote:
>
>
> At 05/24/2017 12:24 PM, Eryu Guan wrote:
> > On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote:
> > >
> > >
> > > At 05/23/2017 07:13 PM, Eryu Guan wrote:
> > > > On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
At 05/24/2017 12:24 PM, Eryu Guan wrote:
On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote:
At 05/23/2017 07:13 PM, Eryu Guan wrote:
On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
[BUG]
If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
generic/143 and
On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote:
>
>
> At 05/23/2017 07:13 PM, Eryu Guan wrote:
> > On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
> > > [BUG]
> > > If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
> > > generic/143 and generic/154, it will
24.05.2017 00:49, Marc MERLIN пишет:
> On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote:
>>> I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it
>>> never worked properly any of those times, sadly.
>>
>> Since the 4.6 total rewrite? There are also recent bug fixes
>
> Only recovery needs to be implemented now.
>
> Thanks,
> Qu
>
Once recovery is implemented, I'll try again.
Just one suggestion: Optionally, It is possible to print filename for
these detected blocks. For ex, if corruption happened on a
old/unwanted archived log file
At 03/28/2017 02:13 AM, Goldwyn Rodrigues wrote:
On 03/27/2017 12:36 PM, David Sterba wrote:
On Mon, Mar 27, 2017 at 12:29:57PM -0500, Goldwyn Rodrigues wrote:
From: Goldwyn Rodrigues
We are facing the same problem with EDQUOT which was experienced with
ENOSPC. Not
This patch adds compression and decompression trace points for the
purpose of debugging.
Signed-off-by: Anand Jain
---
Note:
I have used same trace function for both compress and decompress
as I wanted to maintain compress and decompress debug data aligned.
Instead of sending each argument of struct compressed_bio, send
the compressed_bio itself.
Also by having struct compressed_bio in btrfs_decompress_bio()
it would help tracing.
Signed-off-by: Anand Jain
---
This patch is preparatory for the up coming patch
btrfs: add
In verify_dir_item, it wants to printk name_len of dir_item but
printk data_len acutally.
Fix it by calling btrfs_dir_name_len instead of btrfs_dir_data_len.
Signed-off-by: Su Yue
---
fs/btrfs/dir-item.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
At 05/23/2017 07:13 PM, Eryu Guan wrote:
On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
[BUG]
If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
generic/143 and generic/154, it will cause false alert like:
cp: failed to clone '/mnt/test/test-154/file2' from
On Tue, May 23, 2017 at 02:53:21PM -0700, Marc MERLIN wrote:
> On Tue, May 23, 2017 at 03:51:43PM -0600, Chris Murphy wrote:
> > On Tue, May 23, 2017 at 3:49 PM, Marc MERLIN wrote:
> > > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote:
> > >> > I've tried an ext4 to
On Tue, May 23, 2017 at 03:51:43PM -0600, Chris Murphy wrote:
> On Tue, May 23, 2017 at 3:49 PM, Marc MERLIN wrote:
> > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote:
> >> > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it
> >> > never worked
On Tue, May 23, 2017 at 02:49:43PM -0700, Marc MERLIN wrote:
> On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote:
> > > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it
> > > never worked properly any of those times, sadly.
> >
> > Since the 4.6 total rewrite?
On Tue, May 23, 2017 at 3:49 PM, Marc MERLIN wrote:
> On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote:
>> > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it
>> > never worked properly any of those times, sadly.
>>
>> Since the 4.6 total
On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote:
> > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it
> > never worked properly any of those times, sadly.
>
> Since the 4.6 total rewrite? There are also recent bug fixes related
> to convert in the changelog, it
On Tue, May 23, 2017 at 11:00 AM, Marc MERLIN wrote:
> On Thu, May 04, 2017 at 03:55:28AM +, Duncan wrote:
>> > But that alone may not fix it, I think you need a newer kernel...
>>
>> Well, while the 4.4 LTS kernel series /is/ getting a bit long in the
>> tooth by now, it's
Am Tue, 23 May 2017 07:21:33 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-05-22 22:07, Chris Murphy wrote:
> > On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN
> > wrote:
> >> On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote:
> [...]
>
On Mon, May 22, 2017 at 09:19:34AM +, Duncan wrote:
> btrfs check is userspace, not kernelspace. The btrfs-transacti threads
That was my understanding, yes, but since I got it to starve my system,
including in kernel OOM issues I pasted in my last message and just
referenced in
On Thu, May 04, 2017 at 03:55:28AM +, Duncan wrote:
> > But that alone may not fix it, I think you need a newer kernel...
>
> Well, while the 4.4 LTS kernel series /is/ getting a bit long in the
> tooth by now, it's still the second newest LTS series available, 4.9
> being the newest.
>
>
On Tue, May 02, 2017 at 05:01:02AM +, Duncan wrote:
> Marc MERLIN posted on Mon, 01 May 2017 20:23:46 -0700 as excerpted:
>
> > Also, how is --mode=lowmem being useful?
>
> FWIW, I just watched your talk that's linked from the wiki, and wondered
> what you were doing these days as I hadn't
On Tue, May 23, 2017 at 07:21:33AM -0400, Austin S. Hemmelgarn wrote:
> > Yeah although I have no idea how much swap is needed for it to
> > succeed. I'm not sure what the relationship is to fs metadata chunk
> > size to btrfs check RAM requirement is; but if it wants all of the
> > metadata in
Okay, I did multiple (upto 11) corruption on the same file. Seems like
it says 'CORRUPTED' when we corrupt two continuous data stripes and
reports 'RECOVERABLE' whenever possible.It looks fine. You can find
the logs and test-scripts on below link. thanks.
On 2017-05-22 22:07, Chris Murphy wrote:
On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote:
On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote:
On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote:
I already have 24GB of RAM in that machine,
On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
> [BUG]
> If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
> generic/143 and generic/154, it will cause false alert like:
> cp: failed to clone '/mnt/test/test-154/file2' from
> '/mnt/test/test-154/file1': Invalid
On 19.05.2017 20:39, Liu Bo wrote:
> We commit transaction in order to reclaim space from pinned bytes because
> it could process delayed refs, and in may_commit_transaction(), we check
> first if pinned bytes are enough for the required space, we then check if
> that plus bytes reserved for
[BUG]
If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
generic/143 and generic/154, it will cause false alert like:
cp: failed to clone '/mnt/test/test-154/file2' from '/mnt/test/test-154/file1':
Invalid argument
[REASON]
It is caused by _test_cycle_mount function, which
Hit "Send" a little too early:
More complete workaround would be delayed cleanup. What about
(re-)mount time? (Should also handle qgroups remaining
... after subvolumes deleted on previous kernels.)
--
With Best Regards,
Marat Khalili
On 23/05/17 08:38, Marat Khalili wrote:
Just some
-Dhillon/BtrFS-QGroups-uapi-improvements/20170523-111746
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_a
-pr_debug-deflate-lzo/20170523-110651
config: x86_64-kexec (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
fs/btrfs/lzo.c: In fu
30 matches
Mail list logo