On 24 April 2015 12:41:38 EEST, Janne Blomqvist <[email protected]> 
wrote:
>On 2015-04-24 02:03, Moe Jette wrote:
>>
>> Slurm version 14.11.6 is now available with quite a few bug fixes as
>> listed below.
>>
>> Slurm downloads are available from
>> http://slurm.schedmd.com/download.html
>>
>> * Changes in Slurm 14.11.6
>> ==========================
>
>[snip]
>
>>   -- Enable compiling without optimizations and with debugging
>symbols by
>>      default. Disable this by configuring with --disable-debug.
>
>Always including debug symbols is good (the only cost is a little bit
>of 
>disk space, should never really be a problem), but disabling 
>optimization by default?? In our environment, slurmctld consumes a 
>decent chunk of cpu time, I would loathe to see it getting a lot (?) 
>slower.
>
>Typically, problems which are "fixed" by disabling optimization are due
>
>to violations of the C standard or such which for some reason just 
>doesn't happen to trigger with -O0. Perhaps I'm being needlessly harsh 
>here, but I'd prefer if the bugs were fixed properly rather than being 
>papered over like this.
>
>>   -- Use standard statvfs(2) syscall if available, in preference to
>>      non-standard statfs.
>
>This is not actually such a good idea. Prior to Linux kernel 2.6.36 and
>
>glibc 2.13, the implementation of statvfs required checking all entries
>
>in /proc/mounts. If any of those other filesystems are not available 
>(e.g. a hung NFS mount), the statvfs call would thus hang. See e.g.
>
>http://man7.org/linux/man-pages/man2/statvfs.2.html
>
>Not directly related to this change, there is also a bit of silliness
>in 
>the statfs() code for get_tmp_disk(), namely that it assumes that the
>fs 
>record size is the same as the memory page size. As of Linux 2.6 the 
>struct statfs contains a field f_frsize which contains the correct 
>record size. I suggest the attached patch which should fix both of
>these 
>issues.

Hi,

come to think of it, in my patch the type of total_size should be "unsigned 
long long" to avoid potential overflows on 32-bit Linux targets.

Cheers, 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Reply via email to