search for: cache_openers

The cache filter .open has never done any useful work; since its introduction in c10d126f, it appears to exist purely as copy-and-paste from the cow filter (differing only in whether the readonly parameter is massaged before passing on to next). The error filter .open used to track a per-connection handle, but for testing purposes, it was changed to use only global state in commit b33ccbb8. Drop

...update 2019-08-29 16:27:08,367 urlgrabber version = 3.10 2019-08-29 16:27:08,367 trans function "_" = <function _ at 0x7effcd5bf2a8> 2019-08-29 16:27:08,391 combined options: { 'delegate' : { 'async' : None, 'bandwidth' : 0, 'cache_openers': True, 'checkfunc' : None, 'close_connection': 0, 'copy_local' : 0, 'curl_obj' : None, 'data' : None, 'default_speed': 1000000.0, 'delegate' : None, 'failfunc' : <functio...

Am 2019-08-29 16:51, schrieb Gary Stainburn: > On Thursday 29 August 2019 15:45:44 Gordon Messmer wrote: >> On 8/29/19 3:03 AM, Gary Stainburn wrote: >> > https://us-east.repo.webtatic.com/yum/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#60 - "Peer's Certificate issuer is not recognized." >> >> >> What do you see when you run: >>

Hi. Im writing a kernel module to extract some information from kernel, the module is working really fine in an AMD (AMD Athlon(tm) 64 X2 Dual Core Processor 3800+), but, when trying to run the module in a i7 (Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz) Im facing some strange errors (see below). The kernel versions are just the same on both machines (2.6.34.10-0.2-xen #1 SMP x86_64 x86_64 x86_64

Hi. Im writing a kernel module to extract some information from kernel, the module is working really fine in an AMD (AMD Athlon(tm) 64 X2 Dual Core Processor 3800+), but, when trying to run the module in a i7 (Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz) Im facing some strange errors (see below). The kernel versions are just the same on both machines (2.6.34.10-0.2-xen #1 SMP x86_64 x86_64 x86_64

The original plan was to have a background thread doing the reclaim. However that cannot work given the design of filters, because a background thread cannot access the next_ops struct which is only available during requests. Therefore we spread the work over the request threads. Each blk_* function checks whether there is work to do, and if there is will reclaim up to two blocks from the cache

...--disablerepo=\* --enablerepo=epel update [snip] Loading mirror speeds from cached hostfile 2019-08-29 17:23:17,344 combined options: { 'text' : 'epel/x86_64/metalink', 'delegate' : { 'async' : None, 'bandwidth' : 0, 'cache_openers': True, 'checkfunc' : None, 'close_connection': 0, 'copy_local' : 0, 'curl_obj' : None, 'data' : None, 'default_speed': 1000000.0, 'delegate' : None, 'failfunc' : <functio...

The original plan was to have a background thread doing the reclaim. However that cannot work given the design of filters, because a background thread cannot access the next_ops struct which is only available during requests. Therefore we spread the work over the request threads. Each blk_* function checks whether there is work to do, and if there is will reclaim up to two blocks from the cache

While working on adding assertions to pthread_mutex_lock calls, I noticed that the truncate filter's use of mutex didn't really protect us, and isn't really necessary. Cleaning that up also spotted a couple of other potential cleanups. Eric Blake (4): filters: Drop useless .open callbacks truncate: Fix corruption when plugin changes per-connection size truncate: Test for safe

The original plan was to have a background thread doing the reclaim. However that cannot work given the design of filters, because a background thread cannot access the next_ops struct which is only available during requests. Therefore we spread the work over the request threads. Each blk_* function checks whether there is work to do, and if there is will reclaim up to two blocks from the cache

The original plan was to have a background thread doing the reclaim. However that cannot work given the design of filters, because a background thread cannot access the next_ops struct which is only available during requests. Therefore we spread the work over the request threads. Each blk_* function checks whether there is work to do, and if there is will reclaim up to two blocks from the cache

This adds a cache filter, which works like the COW filter in reverse. For realistic use it needs a bit more work, especially to add limits on the size of the cache, a more sensible cache replacement policy, and perhaps some kind of background worker to write dirty blocks out. Rich.

A common idiom where we don't need a per-connection handle is: static void * myplugin_open (int readonly) { static int handle; return &handle; } We need to return some non-NULL value, but we don't care what. This commit defines a macro NBDKIT_HANDLE_NOT_NEEDED which contains a meaningless non-NULL pointer which can be used instead of the above. This is more

Am 2019-08-29 17:36, schrieb Gary Stainburn: > On Thursday 29 August 2019 16:20:00 Alexander Dalloz wrote: >> Hi, >> >> yum uses libcurl behind the scenes and thus NSS and not OpenSSL. >> >> Do you get something indicative when running: >> >> URLGRABBER_DEBUG=1 yum --disablerepo=\* --enablerepo=webtatic >> check-update >> >>

Patch 1 is the same as last time, except for a minor comment fix. Patch 2 should address everything that Eric mentioned in his review, and has been retested. Rich.

The original plan was to have a background thread doing the reclaim. However that cannot work given the design of filters, because a background thread cannot access the next_ops struct which is only available during requests. Therefore we spread the work over the request threads. Each blk_* function checks whether there is work to do, and if there is will reclaim up to two blocks from the cache

This patch series enhances the cache filter in a few ways, primarily adding a "cache-on-read" feature (similar to qemu's copyonread); and adding the ability to limit the cache size and the antecedent of that which is having a method to reclaim cache blocks. As the cache is stored as a sparse temporary file, reclaiming cache blocks simply means punching holes in the temporary file.

v3 was broken by a bad rebase, so let's forget about that one. Compared to v2: - Patch 1 is the same except for a minor comment change. - Patch 2 splits the reclaim code into a separate file (filters/cache/reclaim.c) - Addressed Eric's comments from his review of v2. - Retested on Linux and FreeBSD.

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap