Hi Dave,
> When messages are currently in queue awaiting a response, decrease amount of
> time before attempting cifs_reconnect to SMB_MAX_RTT = 10 seconds. The current
> wait time before attempting to reconnect is currently 2*SMB_ECHO_INTERVAL(120
> seconds) since the last response was recieved.
Am 27.02.2013 17:34, schrieb Jeff Layton:
> On Wed, 27 Feb 2013 12:06:14 +0100
> "Stefan (metze) Metzmacher" wrote:
>
>> Hi Dave,
>>
>>> When messages are currently in queue awaiting a response, decrease amount of
>>> time before attemptin
Am 27.02.2013 23:44, schrieb Dave Chiluk:
> On 02/27/2013 04:40 PM, Steve French wrote:
>> On Wed, Feb 27, 2013 at 4:24 PM, Dave Chiluk
>> wrote:
>>> On 02/27/2013 10:34 AM, Jeff Layton wrote:
>>>> On Wed, 27 Feb 2013 12:06:14 +0100
>>>> "
Hi Jeff,
> There's no reason we have to protect the blocked_hash and file_lock_list
> with the same spinlock. With the tests I have, breaking it in two gives
> a barely measurable performance benefit, but it seems reasonable to make
> this locking as granular as possible.
as file_lock_{list,lock}
Hi Jeff,
> At LSF this year, there was a discussion about the "wishlist" for
> userland file servers. One of the things brought up was the goofy and
> problematic behavior of POSIX locks when a file is closed. Boaz started
> a thread on it here:
>
> http://permalink.gmane.org/gmane.linux.file
Am 16.04.2014 22:00, schrieb Michael Kerrisk (man-pages):
> [CC += Jeremy Allison]
>
> On Wed, Apr 16, 2014 at 8:57 PM, Jeff Layton wrote:
>> Sorry to spam so many lists, but I think this needs widespread
>> distribution and consensus.
>>
>> File-private locks have been merged into Linux for v3.1
Am 17.04.2014 13:52, schrieb Jeff Layton:
> On Thu, 17 Apr 2014 00:42:13 +0200
> "Stefan (metze) Metzmacher" wrote:
>
>> Am 16.04.2014 22:00, schrieb Michael Kerrisk (man-pages):
>>> [CC += Jeremy Allison]
>>>
>>> On Wed, Apr 16, 2014 at 8:5
Am 21.04.2014 15:45, schrieb Jeff Layton:
> File-private locks have been merged into Linux for v3.15, and *now*
> people are commenting that the name and macro definitions for the new
> file-private locks suck.
>
> ...and I can't even disagree. The names and command macros do suck.
>
> We're goin
Am 21.04.2014 21:55, schrieb Jeff Layton:
> On Mon, 21 Apr 2014 21:39:12 +0200
> "Michael Kerrisk (man-pages)" wrote:
>
>> On 04/21/2014 08:46 PM, Rich Felker wrote:
>>> On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker wrote:
>>
Hi Steve,
any comments on this? How can we get this fixed upstream?
Thanks!
metze
Am 10.06.2014 12:03, schrieb Björn Baumbach:
> commit d81b8a40e2ece0a9ab57b1fe1798e291e75bf8fc
> ("CIFS: Cleanup cifs open codepath")
> changed disposition to FILE_OPEN.
>
> Signed-off-by: Björn Baumbach
> Signed
Hi Steve,
> Although I have merged this into cifs-2.6.git for-next, in my testing
> I am also seeing this fail with vers=3.0 (and probably 2.0 and 2.1) so
> I would like to fix that too (and mfsymlinks may be at least as
> important there)
Thanks! When can we expect this to be proposed for 3.16 (
Hi Andreas,
> +#define RICHACE_OWNER_SPECIAL_ID 0
> +#define RICHACE_GROUP_SPECIAL_ID 1
> +#define RICHACE_EVERYONE_SPECIAL_ID 2
> +
> +struct richace {
> + unsigned short e_type;
> + unsigned short e_flags;
> + unsigned inte_mask;
> + union {
> + kuid_t
Hi Andreas,
>> here's another update of the richacl patch queue. The changes since the last
>> posting (https://lwn.net/Articles/638242/) include:
>>
>> * The nfs client now allocates pages for received acls on demand like the
>>server does. It no longer caches the acl size between calls.
>
Hi Andreas,
>> I'm wondering if the size of an ace should be dynamic,
>> which might make it possible to support other ace types
>> in future. E.g. supporting other identities like 128-bit values
>> to make it easier to map Windows SIDS.
>
> I'm working on additionally supporting unmapped user@do
14 matches
Mail list logo
