noatime vs norelatime

[Harry Mangalam]

We're (FINALLY!) bringing up our spiffy new Fhgfs production filesystem and ran into an odd situation.

we mount our XFS filesystems on the storage servers with the recommended noatime option:

===

/dev/sda on /raid1 type xfs (rw,noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k,nobarrier)

===

and those options are being respected on the storage servers, but the fs is still being mounted with the /relatime/ option on the clients

1776 $ cat /proc/mounts | grep fhgfs

fhgfs_fast-scratch /fast-scratch fhgfs rw,relatime 0 0

fhgfs_dfs1 /dfs1 fhgfs rw,relatime 0 0

It looks like our  CentOS 6.4 is using RH's default relatime mount option.<http://goo.gl/1e8ydA>

According to the intertubes, relatime is more efficient than atime, but is it recommended  for Fhgfs?  I suspect that the could be remounted with 'norelatime'.

relatime does populate the access time data of 'stat' and will give us finer control over finding 'old' files, but at what price.  I could try it both ways, but we're anxious to open the FS up and I'm looking for the deeper knowledge of the fhgfs devs.

And how would you force 'norelatime' to be set on the clients? 

hjm

[Christian Mohrbacher]

Am 04/08/2014 02:37 AM, schrieb Harry Mangalam:

We're (FINALLY!) bringing up our spiffy new Fhgfs production filesystem and ran into an odd situation.

good to hear :)

we mount our XFS filesystems on the storage servers with the recommended noatime option:

===

/dev/sda on /raid1 type xfs (rw,noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k,nobarrier)

===

and those options are being respected on the storage servers, but the fs is still being mounted with the /relatime/ option on the clients

Please let me clarify, that the atime setting of the chunks on the servers does not necessarily correspond to the atime settings on the client. The client settings are simply ignored.

1776 $ cat /proc/mounts | grep fhgfs

fhgfs_fast-scratch /fast-scratch fhgfs rw,relatime 0 0

fhgfs_dfs1 /dfs1 fhgfs rw,relatime 0 0

It looks like our  CentOS 6.4 is using RH's default relatime mount option.<http://goo.gl/1e8ydA>

We have FhGFS running on a lot of Scientific Linux and RHEL systems (which are basically identical to CentOS) with the default options (including relatime), so we do not see any problems with that. But as I have already said before, it is ignored, so it doesn't have any effect.

According to the intertubes, relatime is more efficient than atime, but is it recommended  for Fhgfs?  I suspect that the could be remounted with 'norelatime'.

relatime does populate the access time data of 'stat' and will give us finer control over finding 'old' files, but at what price.  I could try it both ways, but we're anxious to open the FS up and I'm looking for the deeper knowledge of the fhgfs devs.

If you want to use relatime, you will have to enable it on the server.


Regards,
Christian

[harry mangalam]

Hi Christian,

 

Thanks for all the info.

 

it looks like the stat structure is behaving as if either noatime (or relatime) is operating. We don't care too much about whether access time is being recorded - we just care about the performance for this filesystem.

 

hjm

 

 

Tue Apr 08 07:47:08 [0.12 0.16 0.21] root@hpc-s:/dfs1

 

 

On Tuesday, April 08, 2014 09:44:59 AM Christian Mohrbacher wrote:

> Am 04/08/2014 02:37 AM, schrieb Harry Mangalam:

> > We're (FINALLY!) bringing up our spiffy new Fhgfs production

> > filesystem and ran into an odd situation.

>

> good to hear :)

>

> > we mount our XFS filesystems on the storage servers with the

> > recommended noatime option:

> > ===

> > /dev/sda on /raid1 type xfs

> > (rw,noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,all

> > ocsize=131072k,nobarrier) ===

> > and those options are being respected on the storage servers, but the

> > fs is still being mounted with the /relatime/ option on the clients

>

> Please let me clarify, that the atime setting of the chunks on the

> servers does not necessarily correspond to the atime settings on the

> client. The client settings are simply ignored.

>

> > 1776 $ cat /proc/mounts | grep fhgfs

> > fhgfs_fast-scratch /fast-scratch fhgfs rw,relatime 0 0

> > fhgfs_dfs1 /dfs1 fhgfs rw,relatime 0 0

> >

> > It looks like our CentOS 6.4 is using RH's default relatime mount

> > option.<http://goo.gl/1e8ydA>

>

> We have FhGFS running on a lot of Scientific Linux and RHEL systems

> (which are basically identical to CentOS) with the default options

> (including relatime), so we do not see any problems with that. But as I

> have already said before, it is ignored, so it doesn't have any effect.

>

> > According to the intertubes, relatime is more efficient than atime,

> > but is it recommended for Fhgfs? I suspect that the could be

> > remounted with 'norelatime'.

> > relatime does populate the access time data of 'stat' and will give us

> > finer control over finding 'old' files, but at what price. I could

> > try it both ways, but we're anxious to open the FS up and I'm looking

> > for the deeper knowledge of the fhgfs devs.

>

> If you want to use relatime, you will have to enable it on the server.

>

>

> Regards,

> Christian

--

 

---

Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine

[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487

415 South Circle View Dr, Irvine, CA, 92697 [shipping]

MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)

---