Re: Please add more info to dmesg output on I/O error

2017-03-01 Thread Timofey Titovets 
2017-03-02 3:40 GMT+03:00 Chris Murphy :
> On Wed, Mar 1, 2017 at 12:38 PM, Kai Krakow  wrote:
>> Am Wed, 1 Mar 2017 19:04:26 +0300
>> schrieb Timofey Titovets :
>>
>>> Hi, today i try move my FS from old HDD to new SSD
>>> While processing i catch I/O error and device remove operation was
>>> canceled
>>>
>>> Dmesg:
>>> [ 1015.010241] blk_update_request: I/O error, dev sda, sector 81353664
>>> [ 1015.010246] BTRFS error (device sdb1): bdev /dev/sda1 errs: wr 0,
>>> rd 23, flush 0, corrupt 0, gen 0
>>> [ 1015.010282] ata5: EH complete
>>> [ 1017.016721] ata5.00: exception Emask 0x0 SAct 0x1 SErr 0x0
>>> action 0x0 [ 1017.016730] ata5.00: irq_stat 0x4008
>>> [ 1017.016737] ata5.00: failed command: READ FPDMA QUEUED
>>> [ 1017.016748] ata5.00: cmd 60/08:80:c0:5b:d9/00:00:04:00:00/40 tag 16
>>> ncq dma 4096 in
>>>res 41/40:00:c0:5b:d9/00:00:04:00:00/40 Emask
>>> 0x409 (media error) 
>>> [ 1017.016754] ata5.00: status: { DRDY ERR }
>>> [ 1017.016757] ata5.00: error: { UNC }
>>> [ 1017.029479] ata5.00: configured for UDMA/133
>>> [ 1017.029506] sd 4:0:0:0: [sda] tag#16 UNKNOWN(0x2003) Result:
>>> hostbyte=0x00 driverbyte=0x08
>>> [ 1017.029511] sd 4:0:0:0: [sda] tag#16 Sense Key : 0x3 [current]
>>> [ 1017.029516] sd 4:0:0:0: [sda] tag#16 ASC=0x11 ASCQ=0x4
>>> [ 1017.029520] sd 4:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 04 d9
>>> 5b c0 00 00 08 00
>>>
>>> At now, i fixed this problem by doing scrub FS and delete damaged
>>> files, but scrub are slow, and if btrfs show me a more info on I/O
>>> error, it's will be more helpful
>>> i.e. something like i getting by scrub:
>>> [ 1260.559180] BTRFS warning (device sdb1): i/o error at logical
>>> 40569896960 on dev /dev/sda1, sector 81351616, root 309, inode 55135,
>>> offset 71278592, length 4096, links 1 (path:
>>> nefelim4ag/.config/skypeforlinux/Cache/data_3)
>>>
>>> Thanks.
>>
>> You should turn off SCT ERC with smartctl or set it to lower values,
>
> Unlikely. The OP suggests single HDD to single SSD. Only if there is
> redundancy is it appropriate to set SCT ERC to a low value like 70
> deciseconds.
>
> If it's a single drive, the thing to do is disable SCT ERC in the case
> it's enabled (?) which might be what's going on, so that there's a
> longer recovery time and maybe the drive figures out the problem and
> recovers the data.
>
> smartctl -l scterc /dev/sdX
>
> That should report back the SCT ERC status. Don't change it until we
> know the configuration.
>
>
> --
> Chris Murphy
> --
> 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-info.html


JFYI:
Data: single
Metadata: dup
It's just a notebook with 2.5 hdd

Guys, thanks, but i don't need a help with solving problem, i already
solved the problem by finding and remove damaged data from FS.
I only say that:
  first message generated after:
  # btrfs device remove /dev/sdXn 
  BTRFS error (device sdb1): bdev /dev/sda1 errs: wr 0, rd 23, flush
0, corrupt 0, gen 0
  It's only notify me that i have a problem with read, but did not say
me "where"

  second message generated after:
  # btrfs scrub start /dev/sdXn
  it's more useful:
  BTRFS warning (device sdb1): i/o error at logical 40569896960 on dev
/dev/sda1, sector 81351616, root 309, inode 55135, offset 71278592,
length 4096, links 1 (path:
nefelim4ag/.config/skypeforlinux/Cache/data_3)

i already understand after first message that i have a bad sectors on
HDD and smart also say me that.
i just want replace a drive, and i understood btrfs behaviour, btrfs
just try keep data save and abort device delete operation on I/O
error.
But btrfs, your are smart enough, please give me more info on error,
what stored on corrupted sector?

  if btrfs show this message early (i.e. after increasing error
counter), then it could save my time (~1,5h while i trying understand
what happen and doing full FS Scrub)

Thanks.

-- 
Have a nice day,
Timofey.
--
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-info.html

Re: Please add more info to dmesg output on I/O error

2017-03-01 Thread Chris Murphy 
On Wed, Mar 1, 2017 at 12:38 PM, Kai Krakow  wrote:
> Am Wed, 1 Mar 2017 19:04:26 +0300
> schrieb Timofey Titovets :
>
>> Hi, today i try move my FS from old HDD to new SSD
>> While processing i catch I/O error and device remove operation was
>> canceled
>>
>> Dmesg:
>> [ 1015.010241] blk_update_request: I/O error, dev sda, sector 81353664
>> [ 1015.010246] BTRFS error (device sdb1): bdev /dev/sda1 errs: wr 0,
>> rd 23, flush 0, corrupt 0, gen 0
>> [ 1015.010282] ata5: EH complete
>> [ 1017.016721] ata5.00: exception Emask 0x0 SAct 0x1 SErr 0x0
>> action 0x0 [ 1017.016730] ata5.00: irq_stat 0x4008
>> [ 1017.016737] ata5.00: failed command: READ FPDMA QUEUED
>> [ 1017.016748] ata5.00: cmd 60/08:80:c0:5b:d9/00:00:04:00:00/40 tag 16
>> ncq dma 4096 in
>>res 41/40:00:c0:5b:d9/00:00:04:00:00/40 Emask
>> 0x409 (media error) 
>> [ 1017.016754] ata5.00: status: { DRDY ERR }
>> [ 1017.016757] ata5.00: error: { UNC }
>> [ 1017.029479] ata5.00: configured for UDMA/133
>> [ 1017.029506] sd 4:0:0:0: [sda] tag#16 UNKNOWN(0x2003) Result:
>> hostbyte=0x00 driverbyte=0x08
>> [ 1017.029511] sd 4:0:0:0: [sda] tag#16 Sense Key : 0x3 [current]
>> [ 1017.029516] sd 4:0:0:0: [sda] tag#16 ASC=0x11 ASCQ=0x4
>> [ 1017.029520] sd 4:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 04 d9
>> 5b c0 00 00 08 00
>>
>> At now, i fixed this problem by doing scrub FS and delete damaged
>> files, but scrub are slow, and if btrfs show me a more info on I/O
>> error, it's will be more helpful
>> i.e. something like i getting by scrub:
>> [ 1260.559180] BTRFS warning (device sdb1): i/o error at logical
>> 40569896960 on dev /dev/sda1, sector 81351616, root 309, inode 55135,
>> offset 71278592, length 4096, links 1 (path:
>> nefelim4ag/.config/skypeforlinux/Cache/data_3)
>>
>> Thanks.
>
> You should turn off SCT ERC with smartctl or set it to lower values,

Unlikely. The OP suggests single HDD to single SSD. Only if there is
redundancy is it appropriate to set SCT ERC to a low value like 70
deciseconds.

If it's a single drive, the thing to do is disable SCT ERC in the case
it's enabled (?) which might be what's going on, so that there's a
longer recovery time and maybe the drive figures out the problem and
recovers the data.

smartctl -l scterc /dev/sdX

That should report back the SCT ERC status. Don't change it until we
know the configuration.


-- 
Chris Murphy
--
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-info.html

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2017-03-01 Thread Qu Wenruo 



At 02/02/2017 08:01 PM, Marc Joliet wrote:

On Sunday 28 August 2016 15:29:08 Kai Krakow wrote:

Hello list!


Hi list

[kernel message snipped]



Btrfs --repair refused to repair the filesystem telling me something
about compressed extents and an unsupported case, wanting me to take an
image and send it to the devs. *sigh*


I haven't tried a repair yet; it's a big file system, and btrfs-check is still
running:

# btrfs check -p /dev/sdd2
Checking filesystem on /dev/sdd2
UUID: f97b3cda-15e8-418b-bb9b-235391ef2a38
parent transid verify failed on 3829276291072 wanted 224274 found 283858
parent transid verify failed on 3829276291072 wanted 224274 found 283858
parent transid verify failed on 3829276291072 wanted 224274 found 283858
parent transid verify failed on 3829276291072 wanted 224274 found 283858


Normal transid error, can't say much about if it's harmless, but at 
least some thing went wrong.



Ignoring transid failure
leaf parent key incorrect 3829276291072
bad block 3829276291072


That's some what a big problem for that tree block.

If this tree block is extent tree block, no wonder why kernel output 
kernel warning and abort transaction.


You could try "btrfs-debug-tree -b 3829276291072 " to show the 
content of the tree block.


If it's an extent tree block, then I'm afraid that's the problem.
Not sure if repair can repair such problem, but at least from what I see 
in btrfs-progs fsck self testcases, it doesn't handle extent tree error 
well.




ERROR: errors found in extent allocation tree or chunk allocation
block group 4722282987520 has wrong amount of free space
failed to load free space cache for block group 4722282987520
checking free space cache [O]
root 32018 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32089 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32091 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32092 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32107 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32189 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32190 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32191 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32265 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32266 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32409 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32410 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32411 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32412 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32413 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32631 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32632 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32633 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32634 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32635 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32636 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32718 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096
root 32732 inode 95066 errors 100, file extent discount
Found file extent holes:
start: 413696, len: 4096


File extent holes are completely fine, one of the few problems we can 
fix safely in btrfs-check.


But previous extent tree one is not.

If lowmem mode also reports the same problems only (file extent discount 
+ extent tree error), then there is a chance that --init-extent-tree may 
help.


But it will be super time consuming though.

Thanks,
Qu


checking fs roots [o]

I know that the "file extend discount" errors are fixable from my previous
email to this ML, but what about the rest?  From looking through the ML
archives it seems that --repair won't be able to fix the transid failures.  It
seems that one person had success with the "usebackuproot" mount

raid1 degraded mount still produce single chunks, writeable mount not allowed

2017-03-01 Thread Chris Murphy 
[1717713.408675] BTRFS warning (device dm-8): missing devices (1)
exceeds the limit (0), writeable mount is not allowed
[1717713.446453] BTRFS error (device dm-8): open_ctree failed

[chris@f25s ~]$ uname -r
4.9.8-200.fc25.x86_64

I thought this was fixed. I'm still getting a one time degraded rw
mount, after that it's no longer allowed, which really doesn't make
any sense because those single chunks are on the drive I'm trying to
mount. I don't understand what problem this proscription is trying to
avoid. If it's OK to mount rw,degraded once, then it's OK to allow it
twice. If it's not OK twice, it's not OK once.


-- 
Chris Murphy
--
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-info.html

Re: Please add more info to dmesg output on I/O error

2017-03-01 Thread Chris Murphy 
On Wed, Mar 1, 2017 at 9:04 AM, Timofey Titovets  wrote:
> Hi, today i try move my FS from old HDD to new SSD
> While processing i catch I/O error and device remove operation was canceled
>
> Dmesg:
> [ 1015.010241] blk_update_request: I/O error, dev sda, sector 81353664
> [ 1015.010246] BTRFS error (device sdb1): bdev /dev/sda1 errs: wr 0,
> rd 23, flush 0, corrupt 0, gen 0
> [ 1015.010282] ata5: EH complete
> [ 1017.016721] ata5.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
> [ 1017.016730] ata5.00: irq_stat 0x4008
> [ 1017.016737] ata5.00: failed command: READ FPDMA QUEUED
> [ 1017.016748] ata5.00: cmd 60/08:80:c0:5b:d9/00:00:04:00:00/40 tag 16
> ncq dma 4096 in
>res 41/40:00:c0:5b:d9/00:00:04:00:00/40 Emask
> 0x409 (media error) 
> [ 1017.016754] ata5.00: status: { DRDY ERR }
> [ 1017.016757] ata5.00: error: { UNC }
> [ 1017.029479] ata5.00: configured for UDMA/133
> [ 1017.029506] sd 4:0:0:0: [sda] tag#16 UNKNOWN(0x2003) Result:
> hostbyte=0x00 driverbyte=0x08
> [ 1017.029511] sd 4:0:0:0: [sda] tag#16 Sense Key : 0x3 [current]
> [ 1017.029516] sd 4:0:0:0: [sda] tag#16 ASC=0x11 ASCQ=0x4
> [ 1017.029520] sd 4:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 04 d9
> 5b c0 00 00 08 00

This is an error reported by the drive to libata. It's not a Btrfs
error or bug. The UNC suggests it's an uncorrectable error, so whether
Btrfs can compensate depends on whether there's redundancy for the
affected sector(s).



> At now, i fixed this problem by doing scrub FS and delete damaged
> files, but scrub are slow, and if btrfs show me a more info on I/O
> error, it's will be more helpful
> i.e. something like i getting by scrub:
> [ 1260.559180] BTRFS warning (device sdb1): i/o error at logical
> 40569896960 on dev /dev/sda1, sector 81351616, root 309, inode 55135,
> offset 71278592, length 4096, links 1 (path:
> nefelim4ag/.config/skypeforlinux/Cache/data_3)

That suggests the problem is with data, not metadata. What is the data
and metadata profile?



-- 
Chris Murphy
--
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-info.html

Re: [PATCH 1/8] nowait aio: Introduce IOCB_FLAG_NOWAIT

2017-03-01 Thread Christoph Hellwig 
On Wed, Mar 01, 2017 at 10:57:17AM -0600, Goldwyn Rodrigues wrote:
> RWF_* ? Isn't that kernel space flags? Or did you intend to say
> IOCB_FLAG_*?

No, they are the flags for preadv2/pwritev2.

> If yes, we maintain two flag fields? aio_reserved1 (perhaps
> renamed to aio_flags2) and aio_flags?

Yes - I'd call it aio_rw_flags or similar.

> aio_reserved1 is also used to return key for the purpose of io_cancel,
> but we should be able to fetch the flags before putting the key value
> there. Still I am not comfortable using the same field for it because it
> will be overwritten when io_submit returns.

It's not - the key is a separate field.  It's just that the two are
defined using a very strange macro switching around their positions
based on the endiannes.

> Which brings me to the next question: What is the purpose of aio_key?
> Why is aio_key set to KIOCB_KEY (which is zero) every time? You are not
> differentiating the request by setting all the iocb's key to zero.

I don't know the history of this rather odd field.
--
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-info.html

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

2017-03-01 Thread Dave Jones 
On Tue, Feb 28, 2017 at 05:12:01PM -0800, Liu Bo wrote:
 > On Mon, Feb 27, 2017 at 11:23:42AM -0500, Dave Jones wrote:
 > > On Mon, Feb 27, 2017 at 07:53:48AM -0800, Liu Bo wrote:
 > >  > On Sun, Feb 26, 2017 at 07:18:42PM -0500, Dave Jones wrote:
 > >  > > Hitting this fairly frequently.. I'm not sure if this is the same bug 
 > > I've
 > >  > > been hitting occasionally since 4.9. The assertion looks new to me at 
 > > least.
 > >  > >
 > >  > 
 > >  > It was recently introduced by my commit and used to catch data loss at 
 > > truncate.
 > >  > 
 > >  > Were you running the test with a mkfs.btrfs -O NO_HOLES?
 > >  > (We just queued a fix for the NO_HOLES case in btrfs-next.)
 > > 
 > > No, a fs created with default mkfs.btrfs options.
 > 
 > I have this patch[1] to fix a bug which results in file hole extent, and this
 > bug could lead us to hit the assertion.
 > 
 > Would you try to run the test w/ it, please?
 > 
 > [1]: https://patchwork.kernel.org/patch/9597281/

Made no difference. Still see the same trace & assertion.

Dave

--
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-info.html

Re: Please add more info to dmesg output on I/O error

2017-03-01 Thread Kai Krakow 
Am Wed, 1 Mar 2017 19:04:26 +0300
schrieb Timofey Titovets :

> Hi, today i try move my FS from old HDD to new SSD
> While processing i catch I/O error and device remove operation was
> canceled
> 
> Dmesg:
> [ 1015.010241] blk_update_request: I/O error, dev sda, sector 81353664
> [ 1015.010246] BTRFS error (device sdb1): bdev /dev/sda1 errs: wr 0,
> rd 23, flush 0, corrupt 0, gen 0
> [ 1015.010282] ata5: EH complete
> [ 1017.016721] ata5.00: exception Emask 0x0 SAct 0x1 SErr 0x0
> action 0x0 [ 1017.016730] ata5.00: irq_stat 0x4008
> [ 1017.016737] ata5.00: failed command: READ FPDMA QUEUED
> [ 1017.016748] ata5.00: cmd 60/08:80:c0:5b:d9/00:00:04:00:00/40 tag 16
> ncq dma 4096 in
>res 41/40:00:c0:5b:d9/00:00:04:00:00/40 Emask
> 0x409 (media error) 
> [ 1017.016754] ata5.00: status: { DRDY ERR }
> [ 1017.016757] ata5.00: error: { UNC }
> [ 1017.029479] ata5.00: configured for UDMA/133
> [ 1017.029506] sd 4:0:0:0: [sda] tag#16 UNKNOWN(0x2003) Result:
> hostbyte=0x00 driverbyte=0x08
> [ 1017.029511] sd 4:0:0:0: [sda] tag#16 Sense Key : 0x3 [current]
> [ 1017.029516] sd 4:0:0:0: [sda] tag#16 ASC=0x11 ASCQ=0x4
> [ 1017.029520] sd 4:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 04 d9
> 5b c0 00 00 08 00
> 
> At now, i fixed this problem by doing scrub FS and delete damaged
> files, but scrub are slow, and if btrfs show me a more info on I/O
> error, it's will be more helpful
> i.e. something like i getting by scrub:
> [ 1260.559180] BTRFS warning (device sdb1): i/o error at logical
> 40569896960 on dev /dev/sda1, sector 81351616, root 309, inode 55135,
> offset 71278592, length 4096, links 1 (path:
> nefelim4ag/.config/skypeforlinux/Cache/data_3)
> 
> Thanks.

You should turn off SCT ERC with smartctl or set it to lower values, or
if that doesn't work with your HDD firmware, increase the timeout of
the scsi driver above 120s. This setup as it is, is not going to work
correctly with btrfs in case of errors.

# smartctl -l scterc,70,70 /dev/sdb

should do the trick if supported. It applies an error correction
timeout of 7 seconds for reading and writing, which is below the kernel
scsi layer timeout of 30 seconds. Otherwise, your drive will fail to
respond for two minutes until the kernel resets the drive. According to
dmesg, this is what happened.

NAS-ready drives usually support this setting, while desktop drives
don't or at least default to standard desktop timeouts.

-- 
Regards,
Kai

Replies to list-only preferred.

--
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-info.html

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2017-03-01 Thread Marc Joliet 
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> > > Also, the image is complete, so I only need to find somewhere where I
> > > can
> > > upload a 9.4 GB file.
> >
> > 
> >
> > Is it a compressed dump? Dumped with btrfs-image -c9?
> 
> It was created with:
> 
> btrfs-image -s -w /dev/sdb2 - | xz -9 --stdout >
> ./btrfs_backup_drive_2.img.xz
> 
> (Mainly because I felt more comfortable using a separate compression
> utility,  not for any rational reason.  Although if you really meant
> "image" above, I have the feeling I'll regret this decision.)

Ah, never mind, it's not as big as I was worried it would be:

% xz -l btrfs_backup_drive.img.xz 
 Str.  Blöcke   Kompr. Unkompr.  Verh.  Check   Dateiname
1   1  9.589,6 MiB 81,4 GiB  0,115  CRC64   
btrfs_backup_drive.img.xz

So 81.4 GB uncompressed.  I have the space to uncompress it if need be.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] btrfs-progs: docs: fix many typos, plus three edits for clarit

2017-03-01 Thread David Sterba 
On Tue, Feb 21, 2017 at 06:14:37PM -0500, Nicholas D Steeves wrote:
> Hi David,
> 
> Please see attached a reasonably thorough patch for all the typos I
> could find in btrfs-progs documentation.  The three edits are very
> minor and look larger than they are because I had to reflow the
> paragraphs.  I'm confident in the quality of the work,

Thank you very much, applied.

> with the
> exception of the following, where I'm not sure what to do:
> 
> Documentation/btrfs-receive.asciidoc
> @@ -66,7 +66,7 @@ tell us where this filesystem is mounted.
>  --dump::
>  dump the stream metadata, one line per operation
>  +
> -Does not require the 'path' parameter. The filesystem chanded.
> +Does not require the 'path' parameter. The filesystem changed.

It should say that the filesystem is not changed, folded to the patch.
--
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-info.html

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2017-03-01 Thread Marc Joliet 
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> > And btrfs check --mode=lowmem is also recommended as in some rare case,
> > low mem mode can detect bug which original mode doesn't.
> 
> I did see differences in output the last time around (again, see my
> previous  messages in this thread), so I'll run with lowmem.

OK, just to prevent confusion: it turns out I never posted the output of 
btrfs-check with --mode=lowmem from the first time I was seeing these errors, 
but I remember the output being (slightly) different from the original mode.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2017-03-01 Thread Marc Joliet 
On Wednesday 01 March 2017 17:32:35 Qu Wenruo wrote:
> At 03/01/2017 04:23 PM, Marc Joliet wrote:
> > On Tuesday 28 February 2017 23:14:54 Marc Joliet wrote:
> >> I think I'm at that point now myself, unless anybody has any other ideas.
> > 
> > For example, could the --init-extent-tree option to btrfs-check help,
> > given
> > that I needed to pass -w to btrfs-image?

(First off, thanks for taking the time to respond!)

> --init-extent-tree should be avoided normally, unless you're 100% sure
> about only extent tree is corrupted, and you have enough faith that
> --init-extent-tree can finish.
> 
> Or it will mostly make things worse.

OK, that's why I asked :) .

> Before trying any RW btrfs check operations, did you run btrfs check on
> the image?

If by image you mean the device in question, not since the last time (see my 
previous messages).  Or can I really run btrfs check on the image?  In any 
case, I started btrfs-check on the device itself.

> And btrfs check --mode=lowmem is also recommended as in some rare case,
> low mem mode can detect bug which original mode doesn't.

I did see differences in output the last time around (again, see my previous 
messages in this thread), so I'll run with lowmem.  It won't be done until 
tomorrow, though.

> (And it also helps us to enhance lowmem mode)

OK

> > Also, the image is complete, so I only need to find somewhere where I can
> > upload a 9.4 GB file.
> 
> Is it a compressed dump? Dumped with btrfs-image -c9?

It was created with:

btrfs-image -s -w /dev/sdb2 - | xz -9 --stdout > ./btrfs_backup_drive_2.img.xz

(Mainly because I felt more comfortable using a separate compression utility, 
not for any rational reason.  Although if you really meant "image" above, I 
have the feeling I'll regret this decision.)

> If so, such large one won't help much unless there is some developer
> really interested in inspecting the image.

When I started without compression, it was something like 46 GB, after only 
1-2 hours, so I expect the uncompressed size to be... very large :-/ .

> Thanks,
> Qu
> 
> > Greetings
> 
> --
> 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-info.html

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/8] nowait aio: Introduce IOCB_FLAG_NOWAIT

2017-03-01 Thread Goldwyn Rodrigues 


On 03/01/2017 09:56 AM, Christoph Hellwig wrote:
> On Wed, Mar 01, 2017 at 07:36:48AM -0800, Christoph Hellwig wrote:
>> Given that we aren't validating aio_flags in older kernels we can't
>> just add this flag as it will be a no-op in older kernels.  I think
>> we will have to add IOCB_CMD_PREADV2/IOCB_CMD_WRITEV2 opcodes that
>> properly validate all reserved fields or flags first.
>>
>> Once we do that I'd really prefer to use the same flags values
>> as preadv2/pwritev2 so that we'll only need one set of flags over
>> sync/async read/write ops.
> 
> I just took another look and we do verify that
> aio_reserved1/aio_reserved2 must be zero.  So I think we can just
> stick RWF_* into aio_reserved1 and fix that problem that way.
> 

RWF_* ? Isn't that kernel space flags? Or did you intend to say
IOCB_FLAG_*? If yes, we maintain two flag fields? aio_reserved1 (perhaps
renamed to aio_flags2) and aio_flags?

aio_reserved1 is also used to return key for the purpose of io_cancel,
but we should be able to fetch the flags before putting the key value
there. Still I am not comfortable using the same field for it because it
will be overwritten when io_submit returns.

Which brings me to the next question: What is the purpose of aio_key?
Why is aio_key set to KIOCB_KEY (which is zero) every time? You are not
differentiating the request by setting all the iocb's key to zero.


-- 
Goldwyn
--
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-info.html

Re: [PATCH v3 00/12] lowmem mode fixes

2017-03-01 Thread David Sterba 
On Tue, Feb 21, 2017 at 04:34:26PM +0800, Qu Wenruo wrote:
> Patches can be fetch from github:
> https://github.com/adam900710/btrfs-progs/tree/lowmem_fixes
> 
> Thanks for reports from Chris Murphy and Christoph Anton Mitterer,
> several new bugs are exposed for lowmem mode fsck.
> 
> Special thank to Christoph, who did rounds of test during the patch
> development.
> 
> The following bugs are fixed in lowmem mode:
> 
> 1) Block group used space false alert
>If a BLOCK_GROUP_ITEM or its first EXTENT/METADATA_ITEM is located at
>the first slot of a leaf, search_slot() used by lowmem mode can
>point to previous leaf, with path->slots[0] beyond valid leaf slots.
> 
>This makes us to read out uninitialized data, and can abort block
>group used space check loop, causing a false alert.
> 
>Fix it with a test case image inside fsck-tests/020/extent-ref-cases
>Also fix all possible backward search.
>Reported by Christoph.
> 
> 2) Partly written prealloc extent false alert
>If a prealloc extent gets partily written, lowmem mode will report
>prealloc extent shouldn't have csum.
> 
>Lowmem mode passed wrong variable to csum checking code, causing it
>to check the whole range of the prealloc extent, making the bug
>happens.
> 
>Fix it with a test case inside fsck-tests/020/extent-ref-cases.
>Reported by Chirs Murphy And Christoph.
> 
> 3) Extent item size false alert.
>Under certain case, btrfs lowmem mode check reports data backref
>lost.
>It's because newly introduced extent item size check aborts normal
>check routine.
> 
>It can happen if a data/metadata extent item has no inline ref.
> 
>Fix it, test case already submitted before and merged, but due to
>fsck-tests framework bugs, it never get called for lowmem mode.
> 
> 4) Compressed inline data extent
>The extra check on inline data extent length doesn't take compression
>into consideration and will cause false alert without outputting any
>error message.
> 
>Fix it and add correct error message output for it.
>Also fix all possible silent error.
>Reported by Christoph.
> 
> 5) fsck-tests Lowmem mode override fixes
>Allow lowmem mode override to get called for all tests, and allow
>them all to pass lowmem mode except fsck-tests/006, which is a
>original repair mode bug.
> 
> 
> changelog:
>   v2:
> More generic forward search bug fix, not restricted to block group
> item.
> Compressed inline extent false alert fix.
> Lowmem fsck-test enhance, to allow it really work.
> Fix walk_down_tree_v2() to continue after non-fatal errors detected
>   v3:
> Update the last patch to make it works better for incoming lowmem
> mode repair patchset.

Thanks for the fixes, applied with a few minor fixups in changelogs.
--
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-info.html

Re: [PATCH v3 10/12] btrfs-progs: fsck-test: Add new test case for file extent false alerts

2017-03-01 Thread David Sterba 
On Tue, Feb 21, 2017 at 04:34:36PM +0800, Qu Wenruo wrote:
> +check_global_prereq xfs_io

> + run_check xfs_io -c "pwrite 0 64K" "$TEST_MNT/file"

> + run_check xfs_io -f -c "pwrite 0 1K" "$TEST_MNT/file"

I've converted this to dd as we don't want to depend on xfsprogs
installed for the tests.
--
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-info.html

Please add more info to dmesg output on I/O error

2017-03-01 Thread Timofey Titovets 
Hi, today i try move my FS from old HDD to new SSD
While processing i catch I/O error and device remove operation was canceled

Dmesg:
[ 1015.010241] blk_update_request: I/O error, dev sda, sector 81353664
[ 1015.010246] BTRFS error (device sdb1): bdev /dev/sda1 errs: wr 0,
rd 23, flush 0, corrupt 0, gen 0
[ 1015.010282] ata5: EH complete
[ 1017.016721] ata5.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 1017.016730] ata5.00: irq_stat 0x4008
[ 1017.016737] ata5.00: failed command: READ FPDMA QUEUED
[ 1017.016748] ata5.00: cmd 60/08:80:c0:5b:d9/00:00:04:00:00/40 tag 16
ncq dma 4096 in
   res 41/40:00:c0:5b:d9/00:00:04:00:00/40 Emask
0x409 (media error) 
[ 1017.016754] ata5.00: status: { DRDY ERR }
[ 1017.016757] ata5.00: error: { UNC }
[ 1017.029479] ata5.00: configured for UDMA/133
[ 1017.029506] sd 4:0:0:0: [sda] tag#16 UNKNOWN(0x2003) Result:
hostbyte=0x00 driverbyte=0x08
[ 1017.029511] sd 4:0:0:0: [sda] tag#16 Sense Key : 0x3 [current]
[ 1017.029516] sd 4:0:0:0: [sda] tag#16 ASC=0x11 ASCQ=0x4
[ 1017.029520] sd 4:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 04 d9
5b c0 00 00 08 00

At now, i fixed this problem by doing scrub FS and delete damaged
files, but scrub are slow, and if btrfs show me a more info on I/O
error, it's will be more helpful
i.e. something like i getting by scrub:
[ 1260.559180] BTRFS warning (device sdb1): i/o error at logical
40569896960 on dev /dev/sda1, sector 81351616, root 309, inode 55135,
offset 71278592, length 4096, links 1 (path:
nefelim4ag/.config/skypeforlinux/Cache/data_3)

Thanks.
-- 
Have a nice day,
Timofey.
--
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-info.html

Re: [PATCH] btrfs-progs: send-dump: add missing newlines

2017-03-01 Thread David Sterba 
On Wed, Feb 22, 2017 at 10:32:46PM +0100, Benedikt Morbach wrote:
> make sure to include newlines after commands that have only one
> argument, such as 'unlink' or 'mkfile'
> 
> changes
> 
> unlink  ./baz.0/file_autimes  ./baz.0/
> atime=2017-02-22T11:59:16+0100 mtime=2017-02-22T11:59:16+0100 
> ctime=2017-02-22T11:59:16+0100
> truncate./baz.0/file_a  size=131072
> chmod   ./baz.0/file_a  mode=644
> utimes  ./baz.0/file_a  
> atime=2017-02-22T11:59:16+0100 mtime=2017-02-22T11:59:16+0100 
> ctime=2017-02-22T11:59:16+0100
> mkfile  ./baz.0/o258-11-0rename  ./baz.0/o258-11-0
>dest=./baz.0/file_b
> utimes  ./baz.0/
> atime=2017-02-22T11:59:16+0100 mtime=2017-02-22T11:59:16+0100 
> ctime=2017-02-22T11:59:16+0100
> 
> to
> 
> unlink  ./baz.0/file_a
> utimes  ./baz.0/
> atime=2017-02-22T11:59:16+0100 mtime=2017-02-22T11:59:16+0100 
> ctime=2017-02-22T11:59:16+0100
> truncate./baz.0/file_a  size=131072
> chmod   ./baz.0/file_a  mode=644
> utimes  ./baz.0/file_a  
> atime=2017-02-22T11:59:16+0100 mtime=2017-02-22T11:59:16+0100 
> ctime=2017-02-22T11:59:16+0100
> mkfile  ./baz.0/o258-11-0
> rename  ./baz.0/o258-11-0   dest=./baz.0/file_b
> utimes  ./baz.0/
> atime=2017-02-22T11:59:16+0100 mtime=2017-02-22T11:59:16+0100 
> ctime=2017-02-22T11:59:16+0100
> 
> Signed-off-by: Benedikt Morbach 

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-info.html

Re: [PATCH 1/8] nowait aio: Introduce IOCB_FLAG_NOWAIT

2017-03-01 Thread Christoph Hellwig 
On Wed, Mar 01, 2017 at 07:36:48AM -0800, Christoph Hellwig wrote:
> Given that we aren't validating aio_flags in older kernels we can't
> just add this flag as it will be a no-op in older kernels.  I think
> we will have to add IOCB_CMD_PREADV2/IOCB_CMD_WRITEV2 opcodes that
> properly validate all reserved fields or flags first.
> 
> Once we do that I'd really prefer to use the same flags values
> as preadv2/pwritev2 so that we'll only need one set of flags over
> sync/async read/write ops.

I just took another look and we do verify that
aio_reserved1/aio_reserved2 must be zero.  So I think we can just
stick RWF_* into aio_reserved1 and fix that problem that way.
--
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-info.html

Re: [PATCH v3] btrfs: remove btrfs_err_str function from uapi/linux/btrfs.h

2017-03-01 Thread David Sterba 
On Wed, Mar 01, 2017 at 02:12:50AM +0300, Dmitry V. Levin wrote:
> btrfs_err_str function is not called from anywhere and is replicated
> in the userspace headers for btrfs-progs.
> 
> It's removal also fixes the following linux/btrfs.h userspace
> compilation error:
> 
> /usr/include/linux/btrfs.h: In function 'btrfs_err_str':
> /usr/include/linux/btrfs.h:740:11: error: 'NULL' undeclared (first use in 
> this function)
> return NULL;
> 
> Suggested-by: Jeff Mahoney 
> Signed-off-by: Dmitry V. Levin 
> Reviewed-by: David Sterba 
> ---
> v3: the patch seems to be lost, resending with updated list of addressees

Indeed, I can't find how or where it got lost, sorry. Added to 4.11
again.
--
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-info.html

Re: [PATCH 7/8] nowait aio: xfs

2017-03-01 Thread Christoph Hellwig 
> @@ -528,12 +528,17 @@ xfs_file_dio_aio_write(
>   ((iocb->ki_pos + count) & mp->m_blockmask)) {
>   unaligned_io = 1;
>   iolock = XFS_IOLOCK_EXCL;
> + if (iocb->ki_flags & IOCB_NOWAIT)
> + return -EAGAIN;

So all unaligned I/O will return -EAGAIN?  Why?  Also please explain
that reason in a comment right here.

> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 1aa3abd..84f981a 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1020,6 +1020,11 @@ xfs_file_iomap_begin(
>   if ((flags & IOMAP_REPORT) ||
>   (xfs_is_reflink_inode(ip) &&
>(flags & IOMAP_WRITE) && (flags & IOMAP_DIRECT))) {
> + /* Allocations due to reflinks */
> + if ((flags & IOMAP_NOWAIT) && !(flags & IOMAP_REPORT)) {
> + error = -EAGAIN;
> + goto out_unlock;
> + }

FYI, this code looks very different in current Linus' tree - I think
you're on some old kernel base.
--
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-info.html

Re: [PATCH 3/8] nowait aio: return if direct write will trigger writeback

2017-03-01 Thread Christoph Hellwig 
On Tue, Feb 28, 2017 at 07:46:06PM -0800, Matthew Wilcox wrote:
> Ugh, this is pretty inefficient.  If that's all you want to know, then
> using the radix tree directly will be far more efficient than spinning
> up all the pagevec machinery only to discard the pages found.
> 
> But what's going to kick these pages out of cache?  Shouldn't we rather
> find the pages, kick them out if clean, start writeback if not, and *then*
> return -EAGAIN?
> 
> So maybe we want to spin up the pagevec machinery after all so we can
> do that extra work?

As pointed out in the last round of these patches I think we really
need to pass a flags argument to filemap_write_and_wait_range to
communicate the non-blocking nature and only return -EAGAIN if we'd
block.  As a bonus that can indeed start to kick the pages out.
--
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-info.html

Re: [PATCH 1/8] nowait aio: Introduce IOCB_FLAG_NOWAIT

2017-03-01 Thread Christoph Hellwig 
On Tue, Feb 28, 2017 at 05:36:03PM -0600, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues 
> 
> This flag informs kernel to bail out if an AIO request will block
> for reasons such as file allocations, or a writeback triggered,
> or would block while allocating requests while performing
> direct I/O.
> 
> IOCB_FLAG_NOWAIT is translated to IOCB_NOWAIT for
> iocb->ki_flags.

Given that we aren't validating aio_flags in older kernels we can't
just add this flag as it will be a no-op in older kernels.  I think
we will have to add IOCB_CMD_PREADV2/IOCB_CMD_WRITEV2 opcodes that
properly validate all reserved fields or flags first.

Once we do that I'd really prefer to use the same flags values
as preadv2/pwritev2 so that we'll only need one set of flags over
sync/async read/write ops.
--
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-info.html

Re: [PATCH 2/8] nowait aio: Return if cannot get hold of i_rwsem

2017-03-01 Thread Christoph Hellwig 
Looks fine,

Reviewed-by: Christoph Hellwig 
--
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-info.html

Re: [PULL] Btrfs cleanups for 4.11, part 2

2017-03-01 Thread David Sterba 
On Wed, Mar 01, 2017 at 09:36:38AM +0200, Nikolay Borisov wrote:
> Kbuild reported the following warning: 
> 
>  fs/btrfs/scrub.c: In function 'check_extent_to_block':
> >> fs/btrfs/scrub.c:4259:24: error: passing argument 1 of 'btrfs_get_extent' 
> >> from incompatible pointer type [-Werror=incompatible-pointer-types]
>  em = btrfs_get_extent(inode, NULL, 0, start, len, 0);
>^
>In file included from fs/btrfs/scrub.c:21:0:
>fs/btrfs/ctree.h:3169:20: note: expected 'struct inode *' but argument is 
> of type 'struct btrfs_inode *'
> struct extent_map *btrfs_get_extent(struct inode *inode, struct page 
> *page,
>^~~~
>cc1: some warnings being treated as errors
> 
> vim +/btrfs_get_extent +4259 fs/btrfs/scrub.c
> 
> 32159242 Gui Hecheng 2014-11-10  4253 if (ordered) {
> 32159242 Gui Hecheng 2014-11-10  4254 
> btrfs_put_ordered_extent(ordered);
> 32159242 Gui Hecheng 2014-11-10  4255 ret = 1;
> 32159242 Gui Hecheng 2014-11-10  4256 goto out_unlock;
> 32159242 Gui Hecheng 2014-11-10  4257 }
> 32159242 Gui Hecheng 2014-11-10  4258  
> 32159242 Gui Hecheng 2014-11-10 @4259 em = btrfs_get_extent(inode, 
> NULL, 0, start, len, 0);
> 32159242 Gui Hecheng 2014-11-10  4260 if (IS_ERR(em)) {
> 32159242 Gui Hecheng 2014-11-10  4261 ret = PTR_ERR(em);
> 32159242 Gui Hecheng 2014-11-10  4262 goto out_unlock;
> 
> I guess changing the definition of btrfs_get_extent in ctree.h got missed to 
> being converted to struct btrfs_inode. Could you be able to fix it up?

Seems the problem got fixed by some following patch. The exact commit
1c8c9c5216295711c79 fails to build but the whole branch is ok. As it's a
minor annoyance I'd rather skip redoing the pull request.
--
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-info.html

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2017-03-01 Thread Qu Wenruo 



At 03/01/2017 04:23 PM, Marc Joliet wrote:

On Tuesday 28 February 2017 23:14:54 Marc Joliet wrote:

I think I'm at that point now myself, unless anybody has any other ideas.


For example, could the --init-extent-tree option to btrfs-check help, given
that I needed to pass -w to btrfs-image?


--init-extent-tree should be avoided normally, unless you're 100% sure 
about only extent tree is corrupted, and you have enough faith that 
--init-extent-tree can finish.


Or it will mostly make things worse.

Before trying any RW btrfs check operations, did you run btrfs check on 
the image?


And btrfs check --mode=lowmem is also recommended as in some rare case, 
low mem mode can detect bug which original mode doesn't.


(And it also helps us to enhance lowmem mode)


Also, the image is complete, so I only need to find somewhere where I can
upload a 9.4 GB file.


Is it a compressed dump? Dumped with btrfs-image -c9?

If so, such large one won't help much unless there is some developer 
really interested in inspecting the image.


Thanks,
Qu



Greetings




--
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-info.html

Re: [PATCH 2/2] Btrfs: remove start_pos

2017-03-01 Thread Qu Wenruo 



At 03/01/2017 09:04 AM, Liu Bo wrote:

@pos, not aligned @start_pos, should be used to check whether the eof page
needs to be marked as readonly, thus @start_pos can be removed.

Signed-off-by: Liu Bo 
---
 fs/btrfs/file.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 0be837b..ef88e6d 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1814,7 +1814,6 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
struct inode *inode = file_inode(file);
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
struct btrfs_root *root = BTRFS_I(inode)->root;
-   u64 start_pos;
u64 end_pos;
ssize_t num_written = 0;
bool sync = (file->f_flags & O_DSYNC) || IS_SYNC(file->f_mapping->host);
@@ -1822,7 +1821,6 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
loff_t pos;
size_t count;
loff_t oldsize;
-   int clean_page = 0;

inode_lock(inode);
err = generic_write_checks(iocb, from);
@@ -1860,7 +1858,6 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,

pos = iocb->ki_pos;
count = iov_iter_count(from);
-   start_pos = round_down(pos, fs_info->sectorsize);
end_pos = round_up(pos + count, fs_info->sectorsize);
oldsize = i_size_read(inode);
if (end_pos > oldsize) {
@@ -1870,8 +1867,6 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
inode_unlock(inode);
goto out;
}
-   if (start_pos > round_up(oldsize, fs_info->sectorsize))
-   clean_page = 1;
}

if (sync)
@@ -1883,7 +1878,7 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
num_written = __btrfs_buffered_write(file, from, pos);
if (num_written > 0)
iocb->ki_pos = pos + num_written;
-   if (clean_page)
+   if (oldsize < pos)
pagecache_isize_extended(inode, oldsize,
i_size_read(inode));


Not familiar with page cache, so I can be totally wrong here.

But what will happen if @oldsize and @pos are in the same page?

For example:
Page startPage start + 4K
| ||  |
  old size pos

Do we still need to call pagecache_iszie_extented() since we will dirty 
that page anyway?


Thanks,
Qu

}




--
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-info.html

Re: [PULL] Btrfs cleanups for 4.11, part 2

2017-03-01 Thread Nikolay Borisov 


On  1.03.2017 00:35, Chris Mason wrote:
> 
> 
> On 02/28/2017 10:09 AM, David Sterba wrote:
>> Hi,
>>
>> this is the second half of the 4.11 batch, the rest of the cleanups.
>> Please
>> pull, thanks.
>>
>> The following changes since commit
>> 6288d6eabc7505f42dda34a2c2962f91914be3a4:
>>
>>   Btrfs: use the correct type when creating cow dio extent (2017-02-22
>> 15:55:03 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
>> for-chris-4.11-part2
>>
>> for you to fetch changes up to 20a7db8ab3f2057a518448b1728d504ffadef65e:
>>
>>   btrfs: add dummy callback for readpage_io_failed and drop checks
>> (2017-02-28 14:29:24 +0100)
>>
> 
> Thanks Dave, I've got this along with Filipe's pull.

Kbuild reported the following warning: 

 fs/btrfs/scrub.c: In function 'check_extent_to_block':
>> fs/btrfs/scrub.c:4259:24: error: passing argument 1 of 'btrfs_get_extent' 
>> from incompatible pointer type [-Werror=incompatible-pointer-types]
 em = btrfs_get_extent(inode, NULL, 0, start, len, 0);
   ^
   In file included from fs/btrfs/scrub.c:21:0:
   fs/btrfs/ctree.h:3169:20: note: expected 'struct inode *' but argument is of 
type 'struct btrfs_inode *'
struct extent_map *btrfs_get_extent(struct inode *inode, struct page *page,
   ^~~~
   cc1: some warnings being treated as errors

vim +/btrfs_get_extent +4259 fs/btrfs/scrub.c

32159242 Gui Hecheng 2014-11-10  4253   if (ordered) {
32159242 Gui Hecheng 2014-11-10  4254   
btrfs_put_ordered_extent(ordered);
32159242 Gui Hecheng 2014-11-10  4255   ret = 1;
32159242 Gui Hecheng 2014-11-10  4256   goto out_unlock;
32159242 Gui Hecheng 2014-11-10  4257   }
32159242 Gui Hecheng 2014-11-10  4258  
32159242 Gui Hecheng 2014-11-10 @4259   em = btrfs_get_extent(inode, NULL, 0, 
start, len, 0);
32159242 Gui Hecheng 2014-11-10  4260   if (IS_ERR(em)) {
32159242 Gui Hecheng 2014-11-10  4261   ret = PTR_ERR(em);
32159242 Gui Hecheng 2014-11-10  4262   goto out_unlock;

I guess changing the definition of btrfs_get_extent in ctree.h got missed to 
being converted to struct btrfs_inode. Could you be able to fix it up?


> 
> -chris
> 
> -- 
> 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-info.html
> 
--
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-info.html

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

2017-03-01 Thread Marc Joliet 
On Tuesday 28 February 2017 23:14:54 Marc Joliet wrote:
> I think I'm at that point now myself, unless anybody has any other ideas.

For example, could the --init-extent-tree option to btrfs-check help, given 
that I needed to pass -w to btrfs-image?

Also, the image is complete, so I only need to find somewhere where I can 
upload a 9.4 GB file.

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.