On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>
> > This mount option significantly reduces writes to the
> > inode table for workloads that perform frequent random
> > writes to preallocated files.
>
> This seems like an overly speci
On 02/20/2015 04:49 PM, Eric Sandeen wrote:
> On 2/20/15 2:50 AM, Michael Kerrisk wrote:
>> Hello Ted,
>>
>> Based on your commit message 0ae45f63d4e, I I wrote the documentation
>> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
>> please check it over and let me know if it's ac
On Fri, 2015-02-20 at 20:59 +0100, Johan Kröckel wrote:
> The scrub is neither cancelable not stoppable. What is the problem?
>
> [ root@host]# btrfs scrub status ./
> scrub status for XX----XX
> scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds
> total by
On 02/20/2015 04:20 PM, Omar Sandoval wrote:
On Tue, Feb 17, 2015 at 02:51:06AM -0800, Omar Sandoval wrote:
Hi,
As it turns out, running with low memory is a really easy way to shake
out undesirable behavior in Btrfs. This can be especially bad when
considering that a memory limit is really eas
On Tue, Feb 17, 2015 at 02:51:06AM -0800, Omar Sandoval wrote:
> Hi,
>
> As it turns out, running with low memory is a really easy way to shake
> out undesirable behavior in Btrfs. This can be especially bad when
> considering that a memory limit is really easy to hit in a container
> (e.g., by us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/02/15 19:59, Johan Kröckel wrote:
> The scrub is neither cancelable not stoppable. What is the
> problem?
>
> [root@host ]# btrfs scrub status ./ scrub status for
> XX----XX scrub started at Thu Feb 19
> 12:41:22 2015,
The scrub is neither cancelable not stoppable. What is the problem?
[root@host ]# btrfs scrub status ./
scrub status for XX----XX
scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds
total bytes scrubbed: 1.56TiB with 0 errors
[root@host ]# btrfs scrub cance
On 2/20/15 2:50 AM, Michael Kerrisk wrote:
> Hello Ted,
>
> Based on your commit message 0ae45f63d4e, I I wrote the documentation
> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
> please check it over and let me know if it's accurate. In particular,
> I added pieces marked wit
On Fri, Feb 20, 2015 at 9:35 AM, David Sterba wrote:
On Thu, Feb 19, 2015 at 08:59:30PM -0500, Chris Mason wrote:
Since commit 8e5cfb55d3f (Btrfs: Make raid_map array be inlined in
btrfs_bio structure), the raid map array is allocated along with the
btrfs bio in alloc_btrfs_bio. The calcula
On Thu, Feb 19, 2015 at 08:59:30PM -0500, Chris Mason wrote:
> Since commit 8e5cfb55d3f (Btrfs: Make raid_map array be inlined in
> btrfs_bio structure), the raid map array is allocated along with the
> btrfs bio in alloc_btrfs_bio. The calculation used to decide how much
> we need to allocate was
On 20 February 2015 at 13:32, Andreas Dilger wrote:
> On Feb 20, 2015, at 1:50 AM, Michael Kerrisk wrote:
>>
>> Hello Ted,
>>
>> Based on your commit message 0ae45f63d4e, I I wrote the documentation
>> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
>> please check it over and
On Feb 20, 2015, at 1:50 AM, Michael Kerrisk wrote:
>
> Hello Ted,
>
> Based on your commit message 0ae45f63d4e, I I wrote the documentation
> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
> please check it over and let me know if it's accurate. In particular,
> I added piec
On 2015.02.19 at 15:36 -0500, Chris Mason wrote:
> Hi Linus,
>
> Please pull my for-linus branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
I get the following warnings during Firefox LTO build. lto1-wpa-stream
outputs the final object files in parallel an
Hello Ted,
Based on your commit message 0ae45f63d4e, I I wrote the documentation
below for MS_LAZYTIME, to go into the mount(2) man page. Could you
please check it over and let me know if it's accurate. In particular,
I added pieces marked with "*" below that were not part of the commit
message an
14 matches
Mail list logo
