"Huang, Ying" writes:
> Hi, Chris,
>
> Chris Mason writes:
>
>> On 19 Jun 2018, at 23:51, Huang, Ying wrote:
> "Huang, Ying" writes:
>
>> Hi, Josef,
>>
>> Do you have time to take a look at the regression?
>>
>> kernel test robot writes:
>>
>>> Greeting,
>>>
Filipe Manana 於 2018-08-02 01:55 寫到:
On Wed, Aug 1, 2018 at 1:54 PM, Filipe Manana
wrote:
On Wed, Aug 1, 2018 at 11:20 AM, robbieko
wrote:
Filipe Manana 於 2018-07-31 19:33 寫到:
On Tue, Jul 31, 2018 at 11:17 AM, robbieko
wrote:
Filipe Manana 於 2018-07-30 20:34 寫到:
On Mon, Jul 30, 2018 at
On Tue, Jul 31, 2018 at 10:51:57PM +, Mark Fasheh wrote:
> Hi Al,
>
> On Tue, Jul 31, 2018 at 11:16:05PM +0100, Al Viro wrote:
> > On Tue, Jul 31, 2018 at 02:10:43PM -0700, Mark Fasheh wrote:
> > > ->getattr from inside the kernel won't always have a vfsmount, check for
> > > this.
> >
> > Re
Mark Fasheh:
> The following patches fix these inconsistencies by introducing a VFS helper
> function which calls the underlying filesystem ->getattr to get our real
> inode number / device pair. The returned values can then be used at those
> places in the kernel where we are incorrectly reportin
Hi Jeff,
On Wed, Aug 01, 2018 at 07:03:54AM -0400, Jeff Layton wrote:
> On Tue, 2018-07-31 at 14:10 -0700, Mark Fasheh wrote:
> > /proc/locks does not always print the correct inode number/device pair.
> > Update lock_get_status() to use vfs_map_unique_ino_dev() to get the real,
> > unique values
Hi,
Here are the kernel details (uname -a):
Device A (Debian 8.10):
Linux DeviceA 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64
GNU/Linux
Device B (Debian 8.11):
Linux DeviceB 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64
GNU/Linux
Device C (Debian 8.9):
Linux DeviceC
On Wed, Aug 1, 2018 at 1:54 PM, Filipe Manana wrote:
> On Wed, Aug 1, 2018 at 11:20 AM, robbieko wrote:
>> Filipe Manana 於 2018-07-31 19:33 寫到:
>>
>>> On Tue, Jul 31, 2018 at 11:17 AM, robbieko wrote:
Filipe Manana 於 2018-07-30 20:34 寫到:
> On Mon, Jul 30, 2018 at 12:28 PM, Fil
On Wed, Aug 01, 2018 at 08:37:31AM +0300, Amir Goldstein wrote:
> > if (inode) {
> > + __u64 ino;
> > + dev_t dev;
> > +
> > + vfs_map_unique_ino_dev(dentry, &ino, &dev);
> > /* userspace relies on this representation of dev_t */
> >
Hi Amir,
On Wed, Aug 01, 2018 at 08:41:14AM +0300, Amir Goldstein wrote:
> > +void vfs_map_unique_ino_dev(struct dentry *dentry, u64 *ino, dev_t *dev)
>
> I find this function name a bit more than function can guaranty.
> It's just a fancy wrapper around ->getattr()
> How about vfs_get_ino_dev()
On Thu, Jul 26, 2018 at 02:53:34PM +0800, Anand Jain wrote:
> When the replace is running the fs_devices::num_devices also includes
> the replace device, however in some operations like device delete and
> balance it needs the actual num_devices without the repalce devices, so
> now the function bt
On 2018-07-31 11:45 PM, MegaBrutal wrote:
> I know that with nodatacow, I take away most of the benefits of BTRFS
> (those are actually hurting database performance – the exact CoW
> nature that is elsewhere a blessing, with databases it's a drawback).
> But are there any advantages of still stick
On Thu, Jul 26, 2018 at 02:53:32PM +0800, Anand Jain wrote:
> From: Anand Jain
>
> %fs_devices can be free-ed by btrfs_free_stale_devices() when the
> close_fs_devices() drops fs_devices::opened to zero, but close_fs_devices
> tries to access the %fs_devices again without the device_list_mutex.
>
On 2018年08月01日 21:27, David Sterba wrote:
> On Tue, Jul 31, 2018 at 02:52:23PM +0800, Qu Wenruo wrote:
>> [BUG]
>> For certains crafted image, whose csum root leaf has missing backref, if
>> we try to trigger write with data csum, it could cause deadlock with the
>> following kernel WARN_ON():
>>
On Tue, Jul 31, 2018 at 02:52:23PM +0800, Qu Wenruo wrote:
> [BUG]
> For certains crafted image, whose csum root leaf has missing backref, if
> we try to trigger write with data csum, it could cause deadlock with the
> following kernel WARN_ON():
> --
> WARNING: CPU: 1 PID: 41 at fs/btrfs/locki
On Tue, Jul 31, 2018 at 04:20:21PM +0900, Misono Tomohiro wrote:
> on-disk devs stats value is updated in btrfs_run_dev_stats(),
> which is called during commit transaction, if device->dev_stats_ccnt
> is not zero.
>
> Since current replace operation does not touch dev_stats_ccnt,
> on-disk dev st
On Tue, Jul 24, 2018 at 10:35:28PM +0200, Adam Borowski wrote:
> On Mon, Jul 23, 2018 at 05:26:24PM +0200, David Sterba wrote:
> > On Wed, Jul 18, 2018 at 12:08:59AM +0200, Adam Borowski wrote:
> (Combined with as-folded)
>
> | | btrfs: allow defrag on a file opened read-only that has rw permissio
On Thu, Jul 26, 2018 at 11:40:54AM +0900, Misono Tomohiro wrote:
> There is no user of this function.
>
> This is forgotten to get removed in commit a575ceeb1338
> ("Btrfs: get rid of unused orphan infrastructure").
>
> Signed-off-by: Misono Tomohiro
Added to misc-next, thanks.
--
To unsubscrib
On Thu, Jul 26, 2018 at 10:22:58AM +0900, Misono Tomohiro wrote:
> Use ERR_CAST() instead of void * to make meaning clear.
>
> Signed-off-by: Misono Tomohiro
Added to misc-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord..
On Wed, Aug 1, 2018 at 11:20 AM, robbieko wrote:
> Filipe Manana 於 2018-07-31 19:33 寫到:
>
>> On Tue, Jul 31, 2018 at 11:17 AM, robbieko wrote:
>>>
>>> Filipe Manana 於 2018-07-30 20:34 寫到:
>>>
On Mon, Jul 30, 2018 at 12:28 PM, Filipe Manana
wrote:
>
>
> On Mon, Jul 30, 2018
On Wed, Aug 01, 2018 at 11:32:24AM +0800, Lu Fengqi wrote:
> PATCH 1-2 remove all unused fs_info parameter from delayed-inode.c
> PATCH 3-5 remove all unused fs_info parameter from root-tree.c
> PATCH 6-7 some cleanup for btrfs_unlink_subvol
Thanks, added to misc-next.
--
To unsubscribe from this
On 1.08.2018 15:19, Qu Wenruo wrote:
>
>
> On 2018年08月01日 20:12, Nikolay Borisov wrote:
>>
>>
>> On 1.08.2018 14:13, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年08月01日 18:08, Nikolay Borisov wrote:
On 1.08.2018 11:08, Qu Wenruo wrote:
> [BUG]
> When mounting certain crafted
On 2018-07-31 23:45, MegaBrutal wrote:
Hi all,
I know it's a decade-old question, but I'd like to hear your thoughts
of today. By now, I became a heavy BTRFS user. Almost everywhere I use
BTRFS, except in situations when it is obvious there is no benefit
(e.g. /var/log, /boot). At home, all my d
On 2018年08月01日 20:12, Nikolay Borisov wrote:
>
>
> On 1.08.2018 14:13, Qu Wenruo wrote:
>>
>>
>> On 2018年08月01日 18:08, Nikolay Borisov wrote:
>>>
>>>
>>> On 1.08.2018 11:08, Qu Wenruo wrote:
[BUG]
When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
when try
On 1.08.2018 14:13, Qu Wenruo wrote:
>
>
> On 2018年08月01日 18:08, Nikolay Borisov wrote:
>>
>>
>> On 1.08.2018 11:08, Qu Wenruo wrote:
>>> [BUG]
>>> When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
>>> when try to recover balance:
>>> --
>>> [ cut here ]
Yes, command output is as is, because I just copied and pasted into the
mail. When I omit the `-t btrfs` part, result is the same.
I'm now trying to rescue what I can, so getting a image dump with
`ddrescue`. It's read about 25% without any errors but it will be expected
to finish in 6 hours. Then
On Wed, Aug 01, 2018 at 05:45:15AM +0200, MegaBrutal wrote:
> But there is still one question that I can't get over: if you store a
> database (e.g. MySQL), would you prefer having a BTRFS volume mounted
> with nodatacow, or would you just simply use ext4?
>
> I know that with nodatacow, I take aw
On 2018年08月01日 18:08, Nikolay Borisov wrote:
>
>
> On 1.08.2018 11:08, Qu Wenruo wrote:
>> [BUG]
>> When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
>> when try to recover balance:
>> --
>> [ cut here ]
>> kernel BUG at fs/btrfs/extent-tree.c
On Tue, 2018-07-31 at 14:10 -0700, Mark Fasheh wrote:
> /proc/locks does not always print the correct inode number/device pair.
> Update lock_get_status() to use vfs_map_unique_ino_dev() to get the real,
> unique values for userspace.
>
> Signed-off-by: Mark Fasheh
> ---
> fs/locks.c | 12 ++
Filipe Manana 於 2018-07-31 19:33 寫到:
On Tue, Jul 31, 2018 at 11:17 AM, robbieko
wrote:
Filipe Manana 於 2018-07-30 20:34 寫到:
On Mon, Jul 30, 2018 at 12:28 PM, Filipe Manana
wrote:
On Mon, Jul 30, 2018 at 12:08 PM, Filipe Manana
wrote:
On Mon, Jul 30, 2018 at 11:21 AM, robbieko
wrote:
On 1.08.2018 11:08, Qu Wenruo wrote:
> [BUG]
> When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
> when try to recover balance:
> --
> [ cut here ]
> kernel BUG at fs/btrfs/extent-tree.c:8956!
> invalid opcode: [#1] PREEMPT SMP NOPTI
> CPU:
On 1 August 2018 at 04:45, MegaBrutal wrote:
> But there is still one question that I can't get over: if you store a
> database (e.g. MySQL), would you prefer having a BTRFS volume mounted
> with nodatacow, or would you just simply use ext4?
>
> I know that with nodatacow, I take away most of the
On Wed, Aug 01, 2018 at 05:45:15AM +0200, MegaBrutal wrote:
> I know it's a decade-old question, but I'd like to hear your thoughts
> of today. By now, I became a heavy BTRFS user. Almost everywhere I use
> BTRFS, except in situations when it is obvious there is no benefit
> (e.g. /var/log, /boot).
MegaBrutal posted on Wed, 01 Aug 2018 05:45:15 +0200 as excerpted:
> But there is still one question that I can't get over: if you store a
> database (e.g. MySQL), would you prefer having a BTRFS volume mounted
> with nodatacow, or would you just simply use ext4?
>
> I know that with nodatacow, I
[BUG]
When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
when try to recover balance:
--
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:8956!
invalid opcode: [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 662 Comm: mount Not tainted 4.18.0-rc1-custom+ #1
Sterling Windmill posted on Mon, 30 Jul 2018 21:06:54 -0400 as excerpted:
> Both drives are identical, Seagate 8TB external drives
Are those the "shingled" SMR drives, normally sold as archive drives and
first commonly available in the 8TB size, and often bought for their
generally better price
35 matches
Mail list logo
