On 10/10/2015 10:15 PM, Kern Sibbald wrote:
> Hello,
>
> >From what I read on the web, this whole thing is a bit of a mess, and
> apparently POSIX requires that O_ACCMODE not be 3 because there are at
> least two bits besides O_RWRD and O_RDONLY. However, on most systems
> O_ACCMODE is 3. It wo
Hello,
>From what I read on the web, this whole thing is a bit of a mess, and
apparently POSIX requires that O_ACCMODE not be 3 because there are at
least two bits besides O_RWRD and O_RDONLY. However, on most systems
O_ACCMODE is 3. It would be hard to consider any part of flags as an
integer b
On 10/10/2015 19:30, Kern Sibbald wrote:
> On 10/10/2015 10:16 AM, Phil Stracchino wrote:
>> On 10/09/15 22:05, Kern Sibbald wrote:
>>> Hello,
>>>
>>> Thanks for pointing this out. I still have problems imagining that they
>>> would define O_RDONLY as 0 in a bitmapped variable!!!
>> It makes more s
On 10/10/2015 10:16 AM, Phil Stracchino wrote:
> On 10/09/15 22:05, Kern Sibbald wrote:
>> Hello,
>>
>> Thanks for pointing this out. I still have problems imagining that they
>> would define O_RDONLY as 0 in a bitmapped variable!!!
> It makes more sense if you think of it as the absence of O_RDWR.
On 10/09/15 22:05, Kern Sibbald wrote:
> Hello,
>
> Thanks for pointing this out. I still have problems imagining that they
> would define O_RDONLY as 0 in a bitmapped variable!!!
It makes more sense if you think of it as the absence of O_RDWR.
--
Phil Stracchino
Babylon Communications
p
decide. The default should be the
> current behavior to not call posix_fadvise(). Also the code path for
> SD/Dir und FD should be separate so enable this for the FD bfile.c
> code only (it seems currently it is the same code).
>
>
>
> Regards,
>
> Robert
>
>
Hello Robert,
Le 08. 10. 15 13:54, Robert Heinzmann a écrit :
> Hi,
>
>> I think you did a really nice investigation work :-)
> Thanks ... was fun :)
>
>> I think that your patch is almost right, and we need to figure if we want to
>> add specific directives for that. I tend to believe right now
-Ursprüngliche Nachricht-
Von: Eric Bollengier [mailto:eric.bolleng...@baculasystems.com]
Gesendet: Mittwoch, 7. Oktober 2015 16:50
An: Robert Heinzmann
Cc: bacula-users@lists.sourceforge.net
Betreff: Re: [Bacula-users] Support for HAVE_POSIX_FADVISE on Bacula Client
Hello Robert,
I thi
free-electrons.com/source/mm/fadvise.c#L115), so there is “right”
>> way to fix this issue
>>
>> - Best approach: there should be a Bacula Option to enable the
>> POSIX_FADV_NOREUSE explicitly for selective bacula Jobs to allow usage of
>> posix_fadvise
be the current behavior to not call
> posix_fadvise(). Also the code path for SD/Dir und FD should be separate so
> enable this for the FD bfile.c code only (it seems currently it is the same
> code).
>
>
>
> Regards,
>
> Robert
>
>
>
> Robert Heinzma
On 7/10/2015 10:57 PM, Robert Heinzmann wrote:
> Hello,
>
> just a short followup. It seems I found the issue causing our file
> system cache to fill up during backup jobs and our virtual platform
> memory usage to increase.
>
> The O_RDONLY mask is “00” on Linux, casing the if flags & O_RDONLY to
me code).
Regards,
Robert
Robert Heinzmann
r.heinzm...@freelancer.traviangames.com
IT-Operations
Travian Games GmbH
Von: Robert Heinzmann [mailto:r.heinzm...@freelancer.traviangames.com]
Gesendet: Mittwoch, 7. Oktober 2015 11:16
An: bacula-users@lists.sourceforge.net
Betreff: [Bacula-users] Support fo
Hello,
we are using bacula on a virtual plattform (> 600 clients) and investiate
moderate swap usage issues / cache usage issues. It seems that during backup of
mysql datafiles (LVM Snapshot), the "cached" memory usage of the server
increases and thus bacula backup reads (only done one) are cac
13 matches
Mail list logo