I don''t need to know the last access time on my files. I looked though the manual, but didn''t find a reference to noatime. Does lustre use that setting? (on the client and/or server) Can I safely turn it off for OST and MDT/MGT volumes as well as clients? On a file system that is read heavily, I would expect to see a performance improvement by using that. Is that true for lustre as well? -- Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080429/67154823/attachment.html
On Tue, 2008-04-29 at 13:09 -0600, Lundgren, Andrew wrote:> I don''t need to know the last access time on my files. I looked > though the manual, but didn''t find a reference to noatime. Does > lustre use that setting? (on the client and/or server)I don''t believe it does because...> On a file system that is read heavily, I would expect to see a > performance improvement by using that. Is that true for lustre as > well?Lustre already handles atime in a pretty efficient manner. Rather than disable it completely we update it "lazily". What that means is that rather than sending immediate and explicit RPCs to update the atime we will delay sending them (for up to 5 seconds, tunable IIRC) and try to send atime updates "piggybacked" with other RPC traffic. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080429/48f12ead/attachment.bin
The problem isn''t with the RPC - its with the additional disk writes. The single lrgest metadata performance gain we achieved was by changing the atime_diff parameter in /proc Brian J. Murrell wrote:> On Tue, 2008-04-29 at 13:09 -0600, Lundgren, Andrew wrote: > >> I don''t need to know the last access time on my files. I looked >> though the manual, but didn''t find a reference to noatime. Does >> lustre use that setting? (on the cl >> >> -- >> >> Adam Cassar >> ICT Manager >> NetRegistry >> ------------------------------------------------------- >> o: 02 9699 6099 >> f: 02 9699 6088 >> d: 02 9641 8609 >> ------------------------------------------------------- >> >> Netregistry Pty Ltd >> www.netregistry.com.au >> PO Box 270 Broadway, NSW 2007 >> tel: +61 2 9699 6099 fax: +61 2 9699 608 >> ient and/or server) >> > > I don''t believe it does because... > > >> On a file system that is read heavily, I would expect to see a >> performance improvement by using that. Is that true for lustre as >> well? >> > > Lustre already handles atime in a pretty efficient manner. Rather than > disable it completely we update it "lazily". What that means is that > rather than sending immediate and explicit RPCs to update the atime we > will delay sending them (for up to 5 seconds, tunable IIRC) and try to > send atime updates "piggybacked" with other RPC traffic. > > b. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss >-- Adam Cassar ICT Manager NetRegistry ------------------------------------------------------- o: 02 9699 6099 f: 02 9699 6088 d: 02 9641 8609 ------------------------------------------------------- Netregistry Pty Ltd www.netregistry.com.au PO Box 270 Broadway, NSW 2007 tel: +61 2 9699 6099 fax: +61 2 9699 608
In my test cluster, I tried mounting with the noatime parameter. It was not supported for the client or the OSTs. You mention the largest performance gain below, did you change that yourself, or did lustre change that with the install? If you changed it, how high did you set it? For our web server, we really don''t care when the files were read, they will be there anyway. The atime info is not valuable to us at all, the writes are just overhead. Thanks! -- Andrew> -----Original Message----- > From: lustre-discuss-bounces at lists.lustre.org > [mailto:lustre-discuss-bounces at lists.lustre.org] On Behalf Of > Adam Cassar > Sent: Tuesday, April 29, 2008 8:11 PM > To: ''Lustre-discuss at clusterfs.com'' > Subject: Re: [Lustre-discuss] lustre and noatime option > > > The problem isn''t with the RPC - its with the additional disk writes. > > The single lrgest metadata performance gain we achieved was > by changing > the atime_diff parameter in /proc > > > Brian J. Murrell wrote: > > On Tue, 2008-04-29 at 13:09 -0600, Lundgren, Andrew wrote: > > > >> I don''t need to know the last access time on my files. I looked > >> though the manual, but didn''t find a reference to noatime. Does > >> lustre use that setting? (on the cl > >> > >> -- > >> > >> Adam Cassar > >> ICT Manager > >> NetRegistry > >> ------------------------------------------------------- > >> o: 02 9699 6099 > >> f: 02 9699 6088 > >> d: 02 9641 8609 > >> ------------------------------------------------------- > >> > >> Netregistry Pty Ltd > >> www.netregistry.com.au > >> PO Box 270 Broadway, NSW 2007 > >> tel: +61 2 9699 6099 fax: +61 2 9699 608 > >> ient and/or server) > >> > > > > I don''t believe it does because... > > > > > >> On a file system that is read heavily, I would expect to see a > >> performance improvement by using that. Is that true for lustre as > >> well? > >> > > > > Lustre already handles atime in a pretty efficient manner. > Rather than > > disable it completely we update it "lazily". What that > means is that > > rather than sending immediate and explicit RPCs to update > the atime we > > will delay sending them (for up to 5 seconds, tunable IIRC) > and try to > > send atime updates "piggybacked" with other RPC traffic. > > > > b. > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > Lustre-discuss mailing list > > Lustre-discuss at lists.lustre.org > > http://lists.lustre.org/mailman/listinfo/lustre-discuss > > > > -- > > Adam Cassar > ICT Manager > NetRegistry > ------------------------------------------------------- > o: 02 9699 6099 > f: 02 9699 6088 > d: 02 9641 8609 > ------------------------------------------------------- > > Netregistry Pty Ltd > www.netregistry.com.au > PO Box 270 Broadway, NSW 2007 > tel: +61 2 9699 6099 fax: +61 2 9699 608 > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss >
On Wed, 2008-04-30 at 12:10 +1000, Adam Cassar wrote:> The problem isn''t with the RPC - its with the additional disk writes.You might want to look at bug 14485 then. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080430/b1394250/attachment.bin
It''s on the mds server (this is in 1.4.x) /proc/fs/lustre/mds/.../atime_diff. Lundgren, Andrew wrote:> In my test cluster, I tried mounting with the noatime parameter. It was not supported for the client or the OSTs. > > You mention the largest performance gain below, did you change that yourself, or did lustre change that with the install? If you changed it, how high did you set it? > > For our web server, we really don''t care when the files were read, they will be there anyway. The atime info is not valuable to us at all, the writes are just overhead. > > Thanks! > > -- > Andrew > > >> -----Original Message----- >> From: lustre-discuss-bounces at lists.lustre.org >> [mailto:lustre-discuss-bounces at lists.lustre.org] On Behalf Of >> Adam Cassar >> Sent: Tuesday, April 29, 2008 8:11 PM >> To: ''Lustre-discuss at clusterfs.com'' >> Subject: Re: [Lustre-discuss] lustre and noatime option >> >> >> The problem isn''t with the RPC - its with the additional disk writes. >> >> The single lrgest metadata performance gain we achieved was >> by changing >> the atime_diff parameter in /proc >> >> >> Brian J. Murrell wrote: >> >>> On Tue, 2008-04-29 at 13:09 -0600, Lundgren, Andrew wrote: >>> >>> >>>> I don''t need to know the last access time on my files. I looked >>>> though the manual, but didn''t find a reference to noatime. Does >>>> lustre use that setting? (on the cl >>>> >>>> -- >>>> >>>> Adam Cassar >>>> ICT Manager >>>> NetRegistry >>>> ------------------------------------------------------- >>>> o: 02 9699 6099 >>>> f: 02 9699 6088 >>>> d: 02 9641 8609 >>>> ------------------------------------------------------- >>>> >>>> Netregistry Pty Ltd >>>> www.netregistry.com.au >>>> PO Box 270 Broadway, NSW 2007 >>>> tel: +61 2 9699 6099 fax: +61 2 9699 608 >>>> ient and/or server) >>>> >>>> >>> I don''t believe it does because... >>> >>> >>> >>>> On a file system that is read heavily, I would expect to see a >>>> performance improvement by using that. Is that true for lustre as >>>> well? >>>> >>>> >>> Lustre already handles atime in a pretty efficient manner. >>> >> Rather than >> >>> disable it completely we update it "lazily". What that >>> >> means is that >> >>> rather than sending immediate and explicit RPCs to update >>> >> the atime we >> >>> will delay sending them (for up to 5 seconds, tunable IIRC) >>> >> and try to >> >>> send atime updates "piggybacked" with other RPC traffic. >>> >>> b. >>> >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >> >>> _______________________________________________ >>> Lustre-discuss mailing list >>> Lustre-discuss at lists.lustre.org >>> http://lists.lustre.org/mailman/listinfo/lustre-discuss >>> >>> >> -- >> >> Adam Cassar >> ICT Manager >> NetRegistry >> ------------------------------------------------------- >> o: 02 9699 6099 >> f: 02 9699 6088 >> d: 02 9641 8609 >> ------------------------------------------------------- >> >> Netregistry Pty Ltd >> www.netregistry.com.au >> PO Box 270 Broadway, NSW 2007 >> tel: +61 2 9699 6099 fax: +61 2 9699 608 >> >> _______________________________________________ >> Lustre-discuss mailing list >> Lustre-discuss at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-discuss >> >> > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss > >-- Adam Cassar ICT Manager NetRegistry ------------------------------------------------------- o: 02 9699 6099 f: 02 9699 6088 d: 02 9641 8609 ------------------------------------------------------- Netregistry Pty Ltd www.netregistry.com.au PO Box 270 Broadway, NSW 2007 tel: +61 2 9699 6099 fax: +61 2 9699 608
Fantastic! Brian J. Murrell wrote:> On Wed, 2008-04-30 at 12:10 +1000, Adam Cassar wrote: > >> The problem isn''t with the RPC - its with the additional disk writes. >> > > You might want to look at bug 14485 then. > > b. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss >-- Adam Cassar ICT Manager NetRegistry ------------------------------------------------------- o: 02 9699 6099 f: 02 9699 6088 d: 02 9641 8609 ------------------------------------------------------- Netregistry Pty Ltd www.netregistry.com.au PO Box 270 Broadway, NSW 2007 tel: +61 2 9699 6099 fax: +61 2 9699 608