Re: BUG: BTRFS and O_DIRECT could lead to wrong checksum and wrong data

On 09/15/2017 05:55 AM, Andrei Borzenkov wrote: > 15.09.2017 01:00, Goffredo Baroncelli пишет: >> >> 2) The second bug, is a more severe bug. If during a writing of a buffer >> with O_DIRECT, the buffer is updated at the same time by a second process, >> the checksum may be incorrect. >> > > Is

Re: BUG: BTRFS and O_DIRECT could lead to wrong checksum and wrong data

15.09.2017 01:00, Goffredo Baroncelli пишет: > > 2) The second bug, is a more severe bug. If during a writing of a buffer with > O_DIRECT, the buffer is updated at the same time by a second process, the > checksum may be incorrect. > Is it btrfs specific? If buffer is updated before it was

Re: snapshots of encrypted directories?

14.09.2017 18:32, Hugo Mills пишет: > On Thu, Sep 14, 2017 at 04:57:39PM +0200, Ulli Horlacher wrote: >> I use encfs on top of btrfs. >> I can create btrfs snapshots, but I have no suggestive access to the files >> in these snaspshots, because they look like: >> >> drwx-- framstag users

Re: [PATCH 1/2] btrfs-progs: build: generate all dependency files

On 2017年09月14日 21:41, David Sterba wrote: > On Thu, Sep 14, 2017 at 07:10:46PM +0900, Naohiro Aota wrote: >> We're missing several dependency files like: >> >> $ diff -u <(find -name '*.o'|cut -d. -f2|sort) <(find -name '*.o.d'|cut -d. >> -f2|sort) >>--- /proc/self/fd/112017-09-14

Re: defragmenting best practice?

On 14 September 2017 at 19:53, Austin S. Hemmelgarn wrote: [..] > While it's not for BTRFS< a tool called e4rat might be of interest to you > regarding this. It reorganizes files on an ext4 filesystem so that stuff > used by the boot loader is right at the beginning of the

[PATCH] Btrfs: cleanup 'start' subtraction from try uncompressed inline extent

Was added in: c8b978188c9a0fd3d535c13debd19d522b726f1f "Btrfs: Add zlib compression support" Survive to near time (from 08.10.2008). Because 'start' checked for zero before branch, so it's safe to remove that subtraction. Signed-off-by: Timofey Titovets ---

Re: BUG: BTRFS and O_DIRECT could lead to wrong checksum and wrong data

As far as I know, both of these are basically known issues, with no good solution, other than not using O_DIRECT. Certainly the first issue is one I recognise. The second isn't one I recognise directly, but is unsurprising to me. There have been discussions -- including developers -- on

BUG: BTRFS and O_DIRECT could lead to wrong checksum and wrong data

Hi all, I discovered two bugs when O_DIRECT is used... 1) a corrupted file doesn't return -EIO when O_DIRECT is used Normally BTRFS prevents to access the contents of a corrupted file; however I was able read the content of a corrupted file simply using O_DIRECT # in a new btrfs filesystem,

Re: defragmenting best practice?

Am Thu, 14 Sep 2017 18:48:54 +0100 schrieb Tomasz Kłoczko : > On 14 September 2017 at 16:24, Kai Krakow > wrote: [..] > > Getting e.g. boot files into read order or at least nearby improves > > boot time a lot. Similar for loading applications. >

Re: defragmenting best practice?

On 2017-09-14 13:48, Tomasz Kłoczko wrote: On 14 September 2017 at 16:24, Kai Krakow wrote: [..] Getting e.g. boot files into read order or at least nearby improves boot time a lot. Similar for loading applications. By how much it is possible to improve boot time? Just

Re: [PATCH 02/15] btrfs: Use pagevec_lookup_range_tag()

On Thu, Sep 14, 2017 at 03:18:06PM +0200, Jan Kara wrote: > We want only pages from given range in btree_write_cache_pages() and > extent_write_cache_pages(). Use pagevec_lookup_range_tag() instead of > pagevec_lookup_tag() and remove unnecessary code. > > CC: linux-btrfs@vger.kernel.org > CC:

Re: defragmenting best practice?

On 14 September 2017 at 16:24, Kai Krakow wrote: [..] > Getting e.g. boot files into read order or at least nearby improves > boot time a lot. Similar for loading applications. By how much it is possible to improve boot time? Just please some example which I can try to

Re: [PATCH] Btrfs: fix confusing worker helper info

On Wed, Sep 13, 2017 at 12:09:28PM -0600, Liu Bo wrote: > We've seen the following backtrace stack in ftrace or dmesg log, > > kworker/u16:10-4244 [000] 241942.480955: function: > btrfs_put_ordered_extent > kworker/u16:10-4244 [000] 241942.480956: kernel_stack: trace>

Re: [PATCH 2/2 v2] Btrfs: remove bio_flags which indicates a meta block of log-tree

On Wed, Sep 13, 2017 at 12:18:22PM -0600, Liu Bo wrote: > Since both committing transaction and writing log-tree are doing > plugging on metadata IO, we can unify to use %sync_writers to benefit > both cases, instead of checking bio_flags while writing meta blocks of > log-tree. > > We can remove

Re: defragmenting best practice?

Am Thu, 14 Sep 2017 17:24:34 +0200 schrieb Kai Krakow : Errors corrected, see below... > Am Thu, 14 Sep 2017 14:31:48 +0100 > schrieb Tomasz Kłoczko : > > > On 14 September 2017 at 12:38, Kai Krakow > > wrote: [..] > > >

Re: snapshots of encrypted directories?

On Thu, Sep 14, 2017 at 04:57:39PM +0200, Ulli Horlacher wrote: > I use encfs on top of btrfs. > I can create btrfs snapshots, but I have no suggestive access to the files > in these snaspshots, because they look like: > > drwx-- framstag users- 2017-09-08 11:47:18 >

Re: defragmenting best practice?

Am Thu, 14 Sep 2017 14:31:48 +0100 schrieb Tomasz Kłoczko : > On 14 September 2017 at 12:38, Kai Krakow > wrote: [..] > > > > I suggest you only ever defragment parts of your main subvolume or > > rely on autodefrag, and let bees do optimizing the

snapshots of encrypted directories?

I use encfs on top of btrfs. I can create btrfs snapshots, but I have no suggestive access to the files in these snaspshots, because they look like: drwx-- framstag users- 2017-09-08 11:47:18 uHjprldmxo3-nSfLmcH54HMW drwxr-xr-x framstag users- 2017-09-08 11:47:18

Re: defragmenting best practice?

On 14 September 2017 at 12:38, Kai Krakow wrote: [..] > > I suggest you only ever defragment parts of your main subvolume or rely > on autodefrag, and let bees do optimizing the snapshots. > > Also, I experimented with adding btrfs support to shake, still working > on better

[PATCH 02/15] btrfs: Use pagevec_lookup_range_tag()

We want only pages from given range in btree_write_cache_pages() and extent_write_cache_pages(). Use pagevec_lookup_range_tag() instead of pagevec_lookup_tag() and remove unnecessary code. CC: linux-btrfs@vger.kernel.org CC: David Sterba Signed-off-by: Jan Kara

Re: [PATCH] Btrfs: do not backup tree roots when fsync

On Thu, Sep 14, 2017 at 09:55:48AM +0800, Qu Wenruo wrote: > > > On 2017年09月14日 02:25, Liu Bo wrote: > > It doens't make sense to backup tree roots when doing fsync, since > > during fsync those tree roots have not been consistent on disk. > > > > Signed-off-by: Liu Bo >

Re: [PATCH 2/2] btrfs: build: omit unnecessary -MD flag

On Thu, Sep 14, 2017 at 07:10:56PM +0900, Naohiro Aota wrote: > According to gcc(1), "-MD is equivalent to -M -MF file, except that -E is not > implied." Since the rule in the Makefile is just generating dependency file > and not building object file, it is no use to have "-MD" here. Also, it's >

Re: [PATCH 1/2] btrfs-progs: build: generate all dependency files

On Thu, Sep 14, 2017 at 07:10:46PM +0900, Naohiro Aota wrote: > We're missing several dependency files like: > > $ diff -u <(find -name '*.o'|cut -d. -f2|sort) <(find -name '*.o.d'|cut -d. > -f2|sort) >--- /proc/self/fd/112017-09-14 18:17:44.460564620 +0900 >+++ /proc/self/fd/12

Re: defragmenting best practice?

On 2017-09-14 03:54, Duncan wrote: Austin S. Hemmelgarn posted on Tue, 12 Sep 2017 13:27:00 -0400 as excerpted: The tricky part though is that differing workloads are impacted differently by fragmentation. Using just four generic examples: * Mostly sequential write focused workloads (like

Re: defragmenting best practice?

Am Tue, 12 Sep 2017 18:28:43 +0200 schrieb Ulli Horlacher : > On Thu 2017-08-31 (09:05), Ulli Horlacher wrote: > > When I do a > > btrfs filesystem defragment -r /directory > > does it defragment really all files in this directory tree, even if > > it contains

Re: Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]

On 07/09/2017 16:43, Peter Becker wrote: 2017-09-07 16:37 GMT+02:00 Marco Lorenzo Crociani : [...] I got: 00-49: 1 50-79: 0 80-89: 0 90-99: 1 100:25540 this means that fs has only one block group used under 50% and 1 between 90 and 99% while the rest

[PATCH 1/2] btrfs-progs: build: generate all dependency files

We're missing several dependency files like: $ diff -u <(find -name '*.o'|cut -d. -f2|sort) <(find -name '*.o.d'|cut -d. -f2|sort) --- /proc/self/fd/112017-09-14 18:17:44.460564620 +0900 +++ /proc/self/fd/122017-09-14 18:17:44.460564620 +0900 @@ -3,7 +3,6 @@ /btrfs-corrupt-block

[PATCH 2/2] btrfs: build: omit unnecessary -MD flag

According to gcc(1), "-MD is equivalent to -M -MF file, except that -E is not implied." Since the rule in the Makefile is just generating dependency file and not building object file, it is no use to have "-MD" here. Also, it's overridden and conflicting with the following "-MM" flag. I guess we

Re: defragmenting best practice?

Austin S. Hemmelgarn posted on Tue, 12 Sep 2017 13:27:00 -0400 as excerpted: > The tricky part though is that differing workloads are impacted > differently by fragmentation. Using just four generic examples: > > * Mostly sequential write focused workloads (like security recording > systems)