On 2018/1/25 11:44, Jens Axboe wrote:
On 1/24/18 8:38 PM, Jia-Ju Bai wrote:
After checking all possible call chains to kmalloc here,
my tool finds that kmalloc is never called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a stati
On Sat 20-01-18 18:40:28, Theodore Ts'o wrote:
> On Sat, Jan 20, 2018 at 04:41:00PM +0800, Hongzhi, Song wrote:
> >
> > 329.11 EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts:
> > (null)
> > 329.12 block nbd0: Connection timed out
> > 329.13 block nbd0: shutting down sockets
>
> T
On Mon, Jan 22, 2018 at 10:06:26AM +0800, Hongzhi, Song wrote:
> Hello,
>
> I create a virtual disk-image using qemu-img.
>
> And then I use /dev/nbd to map the image.
>
> I mount the /dev/nbd to a local dir with ext4-format
>
> Finally, I have some trouble about ext4-filesystem and block devic
Hello,
this is about a problem I have identified last month and for which I still
don't have good solution. Some discussion of the problem happened here [1]
where also technical details are posted but culprit of the problem is
relatively simple: Lots of places in kernel (fs code, writeback logic,
From: Tang Junhui
After long time running of random small IO writing,
I reboot the machine, and after the machine power on,
I found bcache got stuck, the stack is:
[root@ceph153 ~]# cat /proc/2510/task/*/stack
[] closure_sync+0x25/0x90 [bcache]
[] bch_journal+0x118/0x2b0 [bcache]
[] bch_journal_m
On 01/21/2018 08:06 PM, Hongzhi, Song wrote:
> Hello,
>
> I create a virtual disk-image using qemu-img.
>
> And then I use /dev/nbd to map the image.
>
> I mount the /dev/nbd to a local dir with ext4-format
>
> Finally, I have some trouble about ext4-filesystem and block device,
> with using de
Hi,
There are some topics that I would like to discuss at LSF/MM:
- In the past year we have discussed a lot how we can integrate the
Open-Channel SSD (OCSSD) spec with zone devices (SMR). This
discussion is both at the interface level and at an in-kernel level.
Now that Damien's and
On Sat, 2018-01-13 at 23:54 +0800, Ming Lei wrote:
> Thanks for your mentioning, then I can find the following comment in
> srp_queuecommand():
>
> /*
>* The SCSI EH thread is the only context from which
> srp_queuecommand()
>* can get invoked for blo
On 01/23/2018 12:35 AM, Matthew Wilcox wrote:
> On Mon, Jan 22, 2018 at 08:28:54PM -0700, Jens Axboe wrote:
>> On 1/22/18 8:18 PM, Goldwyn Rodrigues wrote:
that their application was "already broken". I'd hate for a kernel
upgrade to break them.
I do wish we could make the cha
On 25 Jan 2018, Pavel Goran told this:
> Hello Nix,
>
> Thursday, January 25, 2018, 1:23:19 AM, you wrote:
>
>> This feels wrong to me. If a cache device is writethrough, the cache is
>> a pure optimization: having such a device fail should not lead to I/O
>> failures of any sort, but should only
On 01/25/2018 04:26 PM, Javier Gonzalez wrote:
Hi,
There are some topics that I would like to discuss at LSF/MM:
- In the past year we have discussed a lot how we can integrate the
Open-Channel SSD (OCSSD) spec with zone devices (SMR). This
discussion is both at the interface level
Hello Nix,
Thursday, January 25, 2018, 9:57:25 PM, you wrote:
> On 25 Jan 2018, Pavel Goran told this:
>> Hello Nix,
>>
>> Thursday, January 25, 2018, 1:23:19 AM, you wrote:
>>
>>> This feels wrong to me. If a cache device is writethrough, the cache is
>>> a pure optimization: having such a devi
On 26/01/2018 12:15 PM, Pavel Goran wrote:
> Hello Nix,
>
> Thursday, January 25, 2018, 9:57:25 PM, you wrote:
>
>> On 25 Jan 2018, Pavel Goran told this:
>
>>> Hello Nix,
>>>
>>> Thursday, January 25, 2018, 1:23:19 AM, you wrote:
>>>
This feels wrong to me. If a cache device is writethroug
Hey Coly,
On Thu, Jan 25, 2018 at 8:56 PM, Coly Li wrote:
> In order to make the failure handling simple and fast, I will not
> distinct each bcache device whether it has dirty data on cache set. Once
> the cache set is dirty, all attached bcache devices will be stopped.
Surely it shouldn't stop
On Wed, Jan 24, 2018 at 1:34 AM, wrote:
> you also can ask our dear maintainer Mike, who knows all about bcache,
> but sometiomes he is very busy, It is normally you would hear nothing
> from him for one weeks or two, sometimes maybe three, but never five,
> since the merge window comes.
;) I d
On 16/01/2018 5:11 PM, Hannes Reinecke wrote:
> On 01/14/2018 03:42 PM, Coly Li wrote:
>> In patch "bcache: fix cached_dev->count usage for bch_cache_set_error()",
>> cached_dev_get() is called when creating dc->writeback_thread, and
>> cached_dev_put() is called when exiting dc->writeback_thread.
On 26/01/2018 1:51 PM, Michael Lyle wrote:
> Hey Coly,
>
> On Thu, Jan 25, 2018 at 8:56 PM, Coly Li wrote:
>> In order to make the failure handling simple and fast, I will not
>> distinct each bcache device whether it has dirty data on cache set. Once
>> the cache set is dirty, all attached bcach
From: Tang Junhui
>On Wed, Jan 24, 2018 at 1:34 AM, wrote:
>> you also can ask our dear maintainer Mike, who knows all about bcache,
>> but sometiomes he is very busy, It is normally you would hear nothing
>> from him for one weeks or two, sometimes maybe three, but never five,
>> since the me
18 matches
Mail list logo
