[DRBD-user] Zero time file saving problem from nfs clients on latest rhel 5.4 and drbd-8.3.2

Lars Ellenberg lars.ellenberg at linbit.com
Thu Sep 10 18:25:02 CEST 2009

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Thu, Sep 10, 2009 at 10:45:24AM -0400, diego.remolina at physics.gatech.edu wrote:
> Hi,
> I have discovered an issue which is related to the following configuration.
> Server and Client running RHEL5 Update 4.
> kernel-2.6.18-164.el5
> RPMS on file servers
> drbd-8.3.2-3
> drbd-km-2.6.18_128.7.1.el5-8.3.2-3
> drbd-km-2.6.18_164.el5-8.3.2-3
> pacemaker-libs-1.0.5-4.1
> pacemaker-1.0.5-4.1
> openais-0.80.6-8.el5
> Whenever the servers are booted into the 2.6.18-164 kernel the problem manifests. The problem is pretty much that any file that is created from graphical applications have wrong permissions and a timestamp which is either close to epoch or the wrap around unix time.
> So the timestamps are in years 1970 or 2038. Some files have no permissions set, e.g. --------- or some bad combination of permissions.
> Booting the servers back into the 2.6.18_128.7.1 kernel fixes the problems.
> Has anybody else tried drbd 8.3.2 on rhel 5.4 with the latest kernel and nfs? Have you seen the same problem?

I think it is "impossible" for this to have anything to do with block
device drivers such as DRBD, as on the block level, we neither know nore
care for the _content_, which is submitted.

This will be a generic problem with that kernel and nfs,
or that kernel and nfs on certain file systems.

Nothing to do with DRBD.
But keep us posted, nevertheless.

: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
please don't Cc me, but send to list   --   I'm subscribed

More information about the drbd-user mailing list