search for: sibiling

Martin Schwenke schrieb am 01.03.2023 23:53: > Not perfect, but better... Yes, I am quite happy with the ctdb_killtcp. > For ctdb_killtcp, when it was basically rewritten, we considered adding > options for max_attempts, but decided to see if it was foolproof. We > could now add those options. Patches welcome too... I'll have a look. > MonitorTimeoutCount defaults to 20

Hi Ulrich, [Reviving an old thread - I owe you an answer :-)] On Thu, 9 Mar 2023 17:02:15 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > Martin Schwenke schrieb am 01.03.2023 23:53: > > On Wed, 1 Mar 2023 16:18:58 +0000, Ulrich Sibiller <ulrich.sibiller at atos.net> wrote: > > > which ignores the port and thus matches all connections for

Hi, On 11/15/23 09:33, Ulrich Sibiller wrote: > Thanks for that hint about case sensitivity's performance penalty. > > For clarifaction: The user is doing mainly reads, so does the > "create" you mention also cover opening/reading files? no. Is it a metadata heave small file workload? That will likely be somewhat slower compared to Windows, but not in the order of

Hello Ralph, Thanks for that hint about case sensitivity's performance penalty. For clarifaction: The user is doing mainly reads, so does the "create" you mention also cover opening/reading files? If only _creation_ of files is suffering from that we probably have some other/further performance issue. We have gpfs, which does not offer a case-insensitive mode, neither does the

Hello Ulrich, On 11/10/23 13:47, Ulrich Sibiller via samba wrote: > We have a user that switched from Linux to Windows with his > engineering software. Previously he was using NFS to access data and > there were no performance complaints. > > Now, with Windows, the same procedures take minutes instead of > seconds. the classic workload where Samba performance sucks is when

Hello, We have a user that switched from Linux to Windows with his engineering software. Previously he was using NFS to access data and there were no performance complaints. Now, with Windows, the same procedures take minutes instead of seconds. I created some log files in Samba 4.10.16-25.el7_9 (recompiled with gpfs support and using the gpfs vfs module) with debuglevel 10 to see if

Hi, In current (6140c3177a0330f42411618c3fca28930ea02a21) samba's ctdb/tools/statd_callout_helper I find this comment: notify) ... # we need these settings to make sure that no tcp connections survive # across a very fast failover/failback #echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout #echo 0 > /proc/sys/net/ipv4/tcp_max_tw_buckets #echo 0 >

Hi Ulrich, On Tue, 15 Oct 2024 15:22:51 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > In current (6140c3177a0330f42411618c3fca28930ea02a21) samba's > ctdb/tools/statd_callout_helper I find this comment: > > notify) > ... > # we need these settings to make sure that no tcp connections > survive # across a very fast failover/failback

Martin Schwenke schrieb am 15.02.2023 23:23: > Hi Uli, > > [Sorry for slow response, life is busy...] Thanks for answering anyway! > On Mon, 13 Feb 2023 15:06:26 +0000, Ulrich Sibiller via samba > OK, this part looks kind-of good. It would be interesting to know how > long the entire failover process is taking. What exactly would you define as the begin and end of the

Hi Uli, [Sorry for slow response, life is busy...] On Mon, 13 Feb 2023 15:06:26 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > we are using ctdb 4.15.5 on RHEL8 (Kernel > 4.18.0-372.32.1.el8_6.x86_64) to provide NFS v3 (via tcp) to RHEL7/8 > clients. Whenever an ip takeover happens most clients report > something like this: > [Mon Feb 13 12:21:22

https://bugzilla.samba.org/show_bug.cgi?id=13920 Bug ID: 13920 Summary: --max-delete and dirs being replaced by symlinks on source Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayne

The raid card is an Adaptec 2100S. -----Original Message----- From: Josh Paetzel [mailto:josh at tcbug.org] Sent: Saturday, November 11, 2006 9:35 AM To: tclug-list at mn-linux.org; pjcrump at bitstream.net Subject: Re: [tclug-list] Drives Not Recognized on Dell Poweredge 1550 CentOs install On Saturday 11 November 2006 01:20, Phillip Crump wrote: > I have a new (used)Dell Poweredge 1550

Hello, we are using ctdb 4.15.5 on RHEL8 (Kernel 4.18.0-372.32.1.el8_6.x86_64) to provide NFS v3 (via tcp) to RHEL7/8 clients. Whenever an ip takeover happens most clients report something like this: [Mon Feb 13 12:21:22 2023] nfs: server x.x.253.252 not responding, still trying [Mon Feb 13 12:21:28 2023] nfs: server x.x.253.252 not responding, still trying [Mon Feb 13 12:22:31 2023] nfs: server

https://bugzilla.mindrot.org/show_bug.cgi?id=2205 Bug ID: 2205 Summary: -S does hostname lookup although it is unused Product: Portable OpenSSH Version: 6.5p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at

On Thu, 16 Feb 2023 17:30:37 +0000, Ulrich Sibiller <ulrich.sibiller at atos.net> wrote: > Martin Schwenke schrieb am 15.02.2023 23:23: > > OK, this part looks kind-of good. It would be interesting to know how > > long the entire failover process is taking. > > What exactly would you define as the begin and end of the failover? From "Takeover run

I had lunch with an interesting guy who had gotten .com-money to record the whole bible professionally with good actors (in swedish and english, kjv). The idea was to sell custom made compilations of biblical texts on cd over internet. The company is now out of money (surprise!), but all the material is recorded (about 350 hours) and if anyone gets a good idea on what to use the material to, it

This afternoon I've transferred our Ogg Vorbis Icecast2 streams from darkice to the ices2 encoder. Apologies if you were trying to listen; I had to stop and start the streams a few times. They should be stable now as I'm off down the pub now! As a reminder, the URL for the streams is at http://www.virginradio.co.uk/thestation/listen/ogg.html. Ices2 takes slightly different parameters to

After doing an informal (128k) listening test, I have concluded that I prefer Beta4 over RC2. The 16kHz low-pass on the RC2 encoder makes it sound like FM radio. Both encoders SEEM to have a couple of dB bump at 10kHz. JT --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to