On Wed, Sep 20, 2017 at 05:52:43PM -0600, Liu Bo wrote:
>We had a bug in btrfs compression code which could end up with a
>kernel panic.
>
>This is adding a regression test for the bug and I've also sent a
>kernel patch to fix the bug.
>
>The patch is "Btrfs: fix kernel oops while reading compresse
El martes, 19 de septiembre de 2017 21:33:31 (CEST) Andrei Borzenkov escribió:
> 19.09.2017 14:49, Senén Vidal Blanco пишет:
> > Perfect!! Just what I was looking for.
> > Sorry for the delay, because before doing so, I preferred to test to see
> > if it actually worked.
> >
> > I have a doubt. Th
Dave posted on Wed, 20 Sep 2017 02:38:13 -0400 as excerpted:
> Here's my scenario. Some months ago I built an over-the-top powerful
> desktop computer / workstation and I was looking forward to really
> fantastic performance improvements over my 6 year old Ubuntu machine. I
> installed Arch Linux
shally verma posted on Wed, 20 Sep 2017 16:40:15 +0530 as excerpted:
> Is there any command that i can run to confirm file has been compressed?
There is the quite recently posted (and actively updated since then)
compsize command.
https://github.com/kilobyte/compsize
--
Duncan - List replies
Hi Duncan,
I'm not sure if this will attache to my original message...
Thank you for your reply. For some reason i'm not getting list messages even
tho i know i am subscribed.
I know all to well about the golden rule of data. It has bitten me a few
times. The data on this array is mostly dat
On Mon, Sep 18, 2017 at 01:06:45PM +0530, shally verma wrote:
> Hi
>
> I wanted to test btrfs compression using fio command but somehow
> during fio writes, I don't see code taking route of compression blocks
> where as If I do a copy to btrfs compression enabled mount point then
> I can easily se
On 20/09/17 22:45, Kai Krakow wrote:
Am Wed, 20 Sep 2017 17:51:15 +0200
schrieb Psalle :
On 19/09/17 17:47, Austin S. Hemmelgarn wrote:
(...)
A better option if you can afford to remove a single device from
that array temporarily is to use bcache. Bcache has one specific
advantage in this cas
On September 19, 2017 11:38:13 PM PDT, Dave wrote:
>>On Thu 2017-08-31 (09:05), Ulli Horlacher wrote:
>
>Here's my scenario. Some months ago I built an over-the-top powerful
>desktop computer / workstation and I was looking forward to really
>fantastic performance improvements over my 6 year old
On Thu, Sep 21, 2017 at 12:10:15AM -0400, Zygo Blaxell wrote:
> Now that check_extent_in_eb()'s extent offset filter can be turned off,
> we need a way to do it from userspace.
>
> Add a 'flags' field to the btrfs_logical_ino_args structure to disable extent
> offset filtering, taking the place of
Am Wed, 20 Sep 2017 07:46:52 -0400
schrieb "Austin S. Hemmelgarn" :
> > Fragmentation: Files with a lot of random writes can become
> > heavily fragmented (1+ extents) causing excessive multi-second
> > spikes of CPU load on systems with an SSD or large amount a RAM. On
> > desktops this
On Thu, Sep 21, 2017 at 12:59:42PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 21, 2017 at 12:10:15AM -0400, Zygo Blaxell wrote:
> > Now that check_extent_in_eb()'s extent offset filter can be turned off,
> > we need a way to do it from userspace.
> >
> > Add a 'flags' field to the btrfs_logical_i
On Thu, Sep 21, 2017 at 04:16:35PM -0400, Zygo Blaxell wrote:
> On Thu, Sep 21, 2017 at 12:59:42PM -0700, Darrick J. Wong wrote:
> > On Thu, Sep 21, 2017 at 12:10:15AM -0400, Zygo Blaxell wrote:
> > > Now that check_extent_in_eb()'s extent offset filter can be turned off,
> > > we need a way to do
These are great suggestions. I will test several of them (or all of
them) and report back with my results once I have done the testing.
Thank you! This is a fantastic mailing list.
P.S. I'm inclined to stay with Firefox, but I will definitely test
Chromium vs Firefox after making a series of chang
Am Thu, 21 Sep 2017 22:10:13 +0200
schrieb Kai Krakow :
> Am Wed, 20 Sep 2017 07:46:52 -0400
> schrieb "Austin S. Hemmelgarn" :
>
> > > Fragmentation: Files with a lot of random writes can become
> > > heavily fragmented (1+ extents) causing excessive multi-second
> > > spikes of CPU loa
On 09/19/2017 10:05 AM, Misono, Tomohiro wrote:
Summary:
Cleanup mount path by avoiding calling btrfs_mount() twice.
Right. Needs cleanup.
This is for more understandable code and no functional change.
However this patch diff isn't straight forward to review. Can you
split this into s
On Wed, Sep 20, 2017 at 5:26 PM, Timofey Titovets wrote:
> 2017-09-20 14:10 GMT+03:00 shally verma :
>> Interesting part is I dont see "encoded" under flags. I couldn't
>> understand if flags are retrieved from btrfs file metadata info. As
>> you are running on 4.14 and I am on 4.9
>>
>> So, am st
Summary:
Cleanup mount path by avoiding calling btrfs_mount() twice.
No functional change.
change to v2: split the patch into three parts.
Long Explanation:
btrfs uses mount_subtree() to mount a subvolume directly. This function
needs a vfsmount* of device's root (/), which is a return value of
Remove subvol related part from btrfs_mount() and change its name to
mount_root(). Also, file_system_type having mount_root() is defined
for the third patch.
New btrfs_mount() will be introduced in the third patch.
Signed-off-by: Tomohiro Misono
---
fs/btrfs/super.c | 24 ---
Extract the part related to subvol option from parse_early_options() and
move it to new parse function (parse_subvol_options()).
This is because mount_root() doesn't need to handle subvol options.
Signed-off-by: Tomohiro Misono
---
fs/btrfs/super.c | 75 +
Introduce new btrfs_mount() using previous setups.
This will do:
(1) parse subvol id related options for later use in mount_subtree()
(2) mount device's root by calling vfs_kern_mount() with
btrfs_root_fs_type. As a result, mount_root() is called
(3) return by calling mount_subtree()
The code
> (1) parse subvol id related options for later use in mount_subtree()
> (3) return by calling mount_subtree()
Sorry, this is not mount_subtree(), but mount_subvol().
Thanks,
Tomohiro
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@
Hi
This email is in context of another thread initiated by me (with
Subject: using fio to test btrfs compression).
Just as brief background, I am trying to verify btrfs compression
where I am writing data using
fio, dd or cp command.
In response to my question in another thread:
> Is there any c
22 matches
Mail list logo
