On Jan 24, 2013, at 4:24 PM, Wojciech Puchar
wrote:
>>
> Except it is on paper reliability.
This "on paper" reliability saved my ass numerous times.
For example I had one home NAS server machine with flaky SATA controller that
would not detect one of the four drives from time to time on reboo
On Jan 23, 2013, at 11:09 PM, Mark Felder wrote:
> On Wed, 23 Jan 2013 14:26:43 -0600, Chris Rees wrote:
>
>>
>> So we have to take your word for it?
>> Provide a link if you're going to make assertions, or they're no more than
>> your own opinion.
>
> I've heard this same thing -- every vde
On Nov 8, 2012, at 12:56 PM, Wojciech Puchar
wrote:
>> EC> That thread starts here:
>> EC> http://lists.freebsd.org/pipermail/freebsd-arch/2010-April/010143.html
>> Year 2010! And we still limited by MAXPHYS (128K) transfers :(
> put
> options MAXPHYS=2097152
> in your kernel config.
>
On Nov 7, 2012, at 4:48 PM, Wojciech Puchar
wrote:
>>>
>>> actually FreeBSD defaults are actually good for COMMON usage. and can be
>>> tuned.
>>>
>>> default MAXBSIZE is one exception.
>>
>> "Common usage" is vague. While FreeBSD might do ok for some applications
>> (dev box, simple works
On Oct 23, 2012, at 2:36 AM, Rick Macklem wrote:
> Ivan Voras wrote:
>> On 20 October 2012 13:42, Nikolay Denev wrote:
>>
>>> Here are the results from testing both patches :
>>> http://home.totalterror.net/freebsd/nfstest/results.html
>>> Both tes
On Oct 20, 2012, at 10:45 PM, Outback Dingo wrote:
> On Sat, Oct 20, 2012 at 3:28 PM, Ivan Voras wrote:
>> On 20 October 2012 14:45, Rick Macklem wrote:
>>> Ivan Voras wrote:
>>
I don't know how to interpret the rise in context switches; as this is
kernel code, I'd expect no context
On Oct 20, 2012, at 4:00 PM, Nikolay Denev wrote:
>
> On Oct 20, 2012, at 3:11 PM, Ivan Voras wrote:
>
>> On 20 October 2012 13:42, Nikolay Denev wrote:
>>
>>> Here are the results from testing both patches :
>>> http://home.totalterror.net/freebsd/
On Oct 20, 2012, at 3:11 PM, Ivan Voras wrote:
> On 20 October 2012 13:42, Nikolay Denev wrote:
>
>> Here are the results from testing both patches :
>> http://home.totalterror.net/freebsd/nfstest/results.html
>> Both tests ran for about 14 hours ( a bit too much,
On Oct 20, 2012, at 3:11 PM, Ivan Voras wrote:
> On 20 October 2012 13:42, Nikolay Denev wrote:
>
>> Here are the results from testing both patches :
>> http://home.totalterror.net/freebsd/nfstest/results.html
>> Both tests ran for about 14 hours ( a bit too much,
On Oct 18, 2012, at 6:11 PM, Nikolay Denev wrote:
>
> On Oct 15, 2012, at 5:34 PM, Ivan Voras wrote:
>
>> On 15 October 2012 16:31, Nikolay Denev wrote:
>>>
>>> On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
>>
>>>> http://p
On Oct 15, 2012, at 5:34 PM, Ivan Voras wrote:
> On 15 October 2012 16:31, Nikolay Denev wrote:
>>
>> On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
>
>>> http://people.freebsd.org/~ivoras/diffs/nfscache_lock.patch
>>>
>>> It should apply to HEA
On Oct 18, 2012, at 3:08 AM, Tristan Verniquet wrote:
>
> I want to work with large (1-10G) files in memory but eventually sync them
> back out to disk. The problem is that the sync process appears to lock the
> file in kernel for the duration of the sync, which can run into minutes. This
>
On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
> On 13/10/2012 17:22, Nikolay Denev wrote:
>
>> drc3.patch applied and build cleanly and shows nice improvement!
>>
>> I've done a quick benchmark using iozone over the NFS mount from the Linux
>> host.
&
On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
> On 13/10/2012 17:22, Nikolay Denev wrote:
>
>> drc3.patch applied and build cleanly and shows nice improvement!
>>
>> I've done a quick benchmark using iozone over the NFS mount from the Linux
>> host.
&
On Oct 13, 2012, at 5:05 AM, Rick Macklem wrote:
> I wrote:
>> Oops, I didn't get the "readahead" option description
>> quite right in the last post. The default read ahead
>> is 1, which does result in "rsize * 2", since there is
>> the read + 1 readahead.
>>
>> "rsize * 16" would actually be
On Oct 11, 2012, at 7:20 PM, Nikolay Denev wrote:
> On Oct 11, 2012, at 8:46 AM, Nikolay Denev wrote:
>
>>
>> On Oct 11, 2012, at 1:09 AM, Rick Macklem wrote:
>>
>>> Nikolay Denev wrote:
>>>> On Oct 10, 2012, at 3:18 AM, Rick Macklem
>>&
On Oct 11, 2012, at 8:46 AM, Nikolay Denev wrote:
>
> On Oct 11, 2012, at 1:09 AM, Rick Macklem wrote:
>
>> Nikolay Denev wrote:
>>> On Oct 10, 2012, at 3:18 AM, Rick Macklem
>>> wrote:
>>>
>>>> Nikolay Denev wrote:
>&g
On Oct 11, 2012, at 1:09 AM, Rick Macklem wrote:
> Nikolay Denev wrote:
>> On Oct 10, 2012, at 3:18 AM, Rick Macklem
>> wrote:
>>
>>> Nikolay Denev wrote:
>>>> On Oct 4, 2012, at 12:36 AM, Rick Macklem
>>>> wrote:
On Oct 10, 2012, at 3:18 AM, Rick Macklem wrote:
> Nikolay Denev wrote:
>> On Oct 4, 2012, at 12:36 AM, Rick Macklem
>> wrote:
>>
>>> Garrett Wollman wrote:
>>>> <>>> said:
>>>>
>>>>>> Simple: just use
On Oct 9, 2012, at 5:12 PM, Nikolay Denev wrote:
>
> On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
>
>> Garrett Wollman wrote:
>>> <>> said:
>>>
>>>>> Simple: just use a sepatate mutex for each list that a cache entry
>>
On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
> Garrett Wollman wrote:
>> <> said:
>>
Simple: just use a sepatate mutex for each list that a cache entry
is on, rather than a global lock for everything. This would reduce
the mutex contention, but I'm not sure how significantly
On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
> Garrett Wollman wrote:
>> <> said:
>>
Simple: just use a sepatate mutex for each list that a cache entry
is on, rather than a global lock for everything. This would reduce
the mutex contention, but I'm not sure how significantly
space?
--
Regards,
Nikolay Denev
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
23 matches
Mail list logo
