Discussion of general kernel technical issues

Edgar Fuß | 31 May 2012 14:14

Picon

selectively disabling atime updates?

Walking a directory tree (e.g. during a backup) unnecessarily updates atimes.
Mounting -o noatime is not an option because the atime updates are needed
elsewhere.
Is there an option (overlay mount or such) to present a file system noatime
(or even read-only) to one process (or at one mount point) but "normally"
to other processes (or at another mount point)?
It would probably suffice if the NFS export would update atimes but local
access wouldn't.

J. Hannken-Illjes | 31 May 2012 14:30

Picon

Picon

Re: selectively disabling atime updates?

A null mount should do the job and this fstab entry should work:

	/path/to/orig /path/to/ovarlay null ro,noatime 

--
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)

On May 31, 2012, at 2:14 PM, Edgar Fuß wrote:

> Walking a directory tree (e.g. during a backup) unnecessarily updates atimes.
> Mounting -o noatime is not an option because the atime updates are needed
> elsewhere.
> Is there an option (overlay mount or such) to present a file system noatime
> (or even read-only) to one process (or at one mount point) but "normally"
> to other processes (or at another mount point)?
> It would probably suffice if the NFS export would update atimes but local
> access wouldn't.

Edgar Fuß | 31 May 2012 16:23

Picon

Re: selectively disabling atime updates?

> A null mount should do the job and this fstab entry should work:
> 
> 	/path/to/orig /path/to/ov[e]rlay null ro,noatime 
Unfortunately, that doesn't work. I get
	mount_null: -o atime: option not supported
(yes, that's "atime", not "noatime").

Just mounting ro doesn't seem to stop the atime updates.

Other suggestions to selectively disable atime updates?

I'm on 6.0_BETA/amd64 in case that matters.

Matthias Kretschmer | 31 May 2012 16:32

Picon

Re: selectively disabling atime updates?

On Thu, May 31, 2012 at 04:23:12PM +0200, Edgar Fuß wrote:
> > A null mount should do the job and this fstab entry should work:
> > 
> > 	/path/to/orig /path/to/ov[e]rlay null ro,noatime 
> Unfortunately, that doesn't work. I get
> 	mount_null: -o atime: option not supported
> (yes, that's "atime", not "noatime").
> 
> Just mounting ro doesn't seem to stop the atime updates.
> 
> Other suggestions to selectively disable atime updates?

I would think that the atime updates are generated by
mount_null/nullfs when the corresponding file in the null-mount
is accessed and the nullfs has to access the original file.

How about using fss for it instead.  If I understand you correctly
you want noatime for backup purposes.  So you might just create
a snapshot of the filesystem you want to backup and access the
snapshot when performing the backup.  This should ensure, that the
changes are written to the location specified by fssconfig(8) and
are lost when you unconfigure the fss afterwards.  Has the
nice effect to make the backup from a non-changing set, too.

--
Matthias Kretschmer

Edgar Fuß | 31 May 2012 16:42

Picon

Re: selectively disabling atime updates?

> I would think that the atime updates are generated by
> mount_null/nullfs when the corresponding file in the null-mount
> is accessed and the nullfs has to access the original file.
Yes, probably.

> How about using fss for it instead.
1. fss is still marked experimental.
2. does fss work with WAPL at all?

Matthias Kretschmer | 31 May 2012 16:56

Picon

Re: selectively disabling atime updates?

On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote:
> > How about using fss for it instead.
> 1. fss is still marked experimental.
oh, I have overlooked that.

> 2. does fss work with WAPL at all?
I don't know that.

Another idea is, if lvm is considered stable, to create a low-level
snapshot via lvm after a sync (without an unmount) and then mountig the
snapshot and hoping that WAPL handles the situation nicely.  Backup from
the snapshot, then destroy the lvm-snapshot.

--
Matthias

Paul Goyette | 31 May 2012 17:37

Re: selectively disabling atime updates?

On Thu, 31 May 2012, Matthias Kretschmer wrote:

> On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote:
>>> How about using fss for it instead.
>> 1. fss is still marked experimental.
> oh, I have overlooked that.
>
>> 2. does fss work with WAPL at all?
> I don't know that.

It seems to work for me!  All my FS are WAPBL-enabled, and I always use 
backup -X for snapshot.

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

Ignatios Souvatzis | 1 Jun 2012 08:34

Picon

Re: selectively disabling atime updates?

On Thu, May 31, 2012 at 08:37:06AM -0700, Paul Goyette wrote:
> On Thu, 31 May 2012, Matthias Kretschmer wrote:
> 
> >On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote:
> >>>How about using fss for it instead.
> >>1. fss is still marked experimental.
> >oh, I have overlooked that.
> >
> >>2. does fss work with WAPL at all?
> >I don't know that.
> 
> It seems to work for me!  All my FS are WAPBL-enabled, and I always
> use backup -X for snapshot.

rsync from a snapshot wouldn't work for me on sparc-64 with an
oldish kernel (5.99.something). I must setup one of the slower
machines for at least partial tests, because the main one is
the file server...

Paul, what's your architecture and version?

	-is
--

-- 
seal your e-mail: http://www.gnupg.org/

Paul Goyette | 1 Jun 2012 14:58

Re: selectively disabling atime updates?

On Fri, 1 Jun 2012, Ignatios Souvatzis wrote:

>>>>> How about using fss for it instead.
>>>> 1. fss is still marked experimental.
>>> oh, I have overlooked that.
>>>
>>>> 2. does fss work with WAPL at all?
>>> I don't know that.
>>
>> It seems to work for me!  All my FS are WAPBL-enabled, and I always
>> use backup -X for snapshot.
>
> rsync from a snapshot wouldn't work for me on sparc-64 with an
> oldish kernel (5.99.something). I must setup one of the slower
> machines for at least partial tests, because the main one is
> the file server...
>
> Paul, what's your architecture and version?

I'm completely amd64 here, and currently running 6.99.5

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

David Holland | 1 Jun 2012 11:02

Picon

Re: selectively disabling atime updates?

On Thu, May 31, 2012 at 04:56:26PM +0200, Matthias Kretschmer wrote:
 > > > How about using fss for it instead.
 > > 1. fss is still marked experimental.
 > oh, I have overlooked that.

I'm not sure that should stop you though. Or the marking should be
removed. People use it, it seems to work, it's been a while since
anyone's reported problems that I've noticed.

 > > 2. does fss work with WAPL at all?
 > I don't know that.

It's expected to at this point. (In -6 and -current, but IIRC not in -5.)

--

-- 
David A. Holland
dholland <at> netbsd.org

Edgar Fuß | 1 Jun 2012 12:03

Picon

Re: selectively disabling atime updates?

> How about using fss for it instead.
Well, the point is not that I primarily don't want the atimes to reflect
the backup access. I primarily want to save the time spent on the update.
A find is aproximately twice as fast with noatime.

David Holland | 3 Jun 2012 22:38

Picon

Re: selectively disabling atime updates?

On Fri, Jun 01, 2012 at 12:03:13PM +0200, Edgar Fu? wrote:
 > > How about using fss for it instead.
 > Well, the point is not that I primarily don't want the atimes to reflect
 > the backup access. I primarily want to save the time spent on the update.
 > A find is aproximately twice as fast with noatime.

This makes me think that /etc/daily should take similar steps,
whatever they turn out to be.

--

-- 
David A. Holland
dholland <at> netbsd.org

Edgar Fuß | 11 Jun 2012 15:45

Picon

Re: selectively disabling atime updates?

> This makes me think that /etc/daily should take similar steps,
> whatever they turn out to be.
Yes, allthough my RAIDframe performance test results show that the effect
decreases with larger block sizes.

I can think of two ways to acheive this (each of which may be absurd given
better knowledge of fs internals than I have): Either a per-process switch
disabling atime updates or a way to obtain a read-only clone of a block
device which can be mounted ro,noatime.

Maybe fss is a way to go, but it's still marked experimental in 6.0 and
taking the snapshot may outweigh the later performance gain.

Thor Lancelot Simon | 11 Jun 2012 15:51

Picon

Re: selectively disabling atime updates?

On Mon, Jun 11, 2012 at 03:45:13PM +0200, Edgar Fu? wrote:
> > This makes me think that /etc/daily should take similar steps,
> > whatever they turn out to be.
>
> Yes, allthough my RAIDframe performance test results show that the effect
> decreases with larger block sizes.

You know, it strikes me that access-time updates probably go through the
journal, since they touch the inode.  And *that* makes me think that:

	* Perhaps the access time should not be in the inode, or should
	  be hoisted out of the same disk block as critical inode fields
	  so it can be written without risk of damage to them.

	* Otherwise, some of these not-actually-critical transactions should
	  be buffered somehow before being written to the journal so they
	  can be batched more efficiently.

I suspect the cache-flushing behavior of the journaling code is effectively
destroying the read priority design of the disk sorting strategy, causing
the commit of the atime writes to stall everything and thus really wreck
performance.  I could be way off, but it's a strong hunch.  And I think I
recall seeing the XFS guys take fairly drastic measures to deal with a
similar problem some years ago as well.

Thor

Mouse | 11 Jun 2012 16:17

Re: selectively disabling atime updates?

> I can think of two ways to acheive this (each of which may be absurd
> given better knowledge of fs internals than I have): Either a
> per-process switch disabling atime updates or a way to obtain a
> read-only clone of a block device which can be mounted ro,noatime.

The latter will not work, at least not for FFS and probably not for any
filesystem whose implementation was not specifically designed to
support it.  The problem is that the `read-only' device is changing
behind the filesystem's back.

Unless you mean a read-only *snapshot* of a block device, in which case
you're basically back at snapshots, only at the block device level
instead of the filesystem level.  (Actually, looking at the existing
snapshot support, it's not clear to me that's not exactly what it
already is.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Edgar Fuß | 11 Jun 2012 16:59

Picon

Re: selectively disabling atime updates?

> The problem is that the `read-only' device is changing
> behind the filesystem's back.
Ah, yes, of course. Stupid me!

J. Hannken-Illjes | 11 Jun 2012 16:24

Picon

Picon

Re: selectively disabling atime updates?

On Jun 11, 2012, at 3:45 PM, Edgar Fuß wrote:

>> This makes me think that /etc/daily should take similar steps,
>> whatever they turn out to be.
> Yes, allthough my RAIDframe performance test results show that the effect
> decreases with larger block sizes.
> 
> I can think of two ways to acheive this (each of which may be absurd given
> better knowledge of fs internals than I have): Either a per-process switch
> disabling atime updates or a way to obtain a read-only clone of a block
> device which can be mounted ro,noatime.
> 
> Maybe fss is a way to go, but it's still marked experimental in 6.0 and
> taking the snapshot may outweigh the later performance gain.

No, snapshots are supported in 6.0.  Taking a file system external snapshot
should be a quick task -- taking a file system internal snapshots is a
time consuming task dependent on the size of the file system. 

--
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)

Edgar Fuß | 11 Jun 2012 17:17

Picon

fss status (was: selectively disabling atime updates?)

> No, snapshots are supported in 6.0.
Ah, great!
Someone should adjust the ffsconfig(8) man page, then:

$ man fssconfig | tail -5
BUGS
     The fss(4) driver is experimental.  Be sure you have a backup before you
     use it.

NetBSD 6.0_BETA                January 31, 2005                NetBSD 6.0_BETA

> Taking a file system external snapshot should be a quick task
That means a ffsconfig(8) with the backup argument pointing to a
different file system?
I assume the backup file will roughly need to hold the amount of data
written to the original fs while the snapshot is active. Is it true that
if the backup file is lost or the fs containing it runs out of space
I only lose the snapshot and the original data is unaffected?

J. Hannken-Illjes | 11 Jun 2012 17:25

Picon

Picon

Re: fss status (was: selectively disabling atime updates?)

On Jun 11, 2012, at 5:17 PM, Edgar Fuß wrote:

>> No, snapshots are supported in 6.0.
> Ah, great!
> Someone should adjust the ffsconfig(8) man page, then:
> 
> $ man fssconfig | tail -5
> BUGS
>     The fss(4) driver is experimental.  Be sure you have a backup before you
>     use it.
> 
> NetBSD 6.0_BETA                January 31, 2005                NetBSD 6.0_BETA

Thats a bug.

>> Taking a file system external snapshot should be a quick task
> That means a ffsconfig(8) with the backup argument pointing to a
> different file system?
> I assume the backup file will roughly need to hold the amount of data
> written to the original fs while the snapshot is active. Is it true that
> if the backup file is lost or the fs containing it runs out of space
> I only lose the snapshot and the original data is unaffected?

Yes and yes.

--
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)

Thor Lancelot Simon | 11 Jun 2012 17:27

Picon

Re: fss status (was: selectively disabling atime updates?)

On Mon, Jun 11, 2012 at 05:17:06PM +0200, Edgar Fu? wrote:
> 
> > Taking a file system external snapshot should be a quick task
> That means a ffsconfig(8) with the backup argument pointing to a
> different file system?

Yes, but I have to question whether and why it would improve performance
in this case.  The stream of atime updates is still happening on the
underlying filesystem, and that is still where you will be doing almost
all of your reads from.

Thor

Edgar Fuß | 11 Jun 2012 17:52

Picon

selectively disabling atime updates?

> Yes, but I have to question whether and why it would improve performance
> in this case.  The stream of atime updates is still happening on the
> underlying filesystem, and that is still where you will be doing almost
> all of your reads from.
My intent was to mount the snapshot ro,noatime and operate on that.
Am I again missing something stupid?

Thor Lancelot Simon | 11 Jun 2012 19:03

Picon

Re: selectively disabling atime updates?

On Mon, Jun 11, 2012 at 05:52:27PM +0200, Edgar Fu? wrote:
> > Yes, but I have to question whether and why it would improve performance
> > in this case.  The stream of atime updates is still happening on the
> > underlying filesystem, and that is still where you will be doing almost
> > all of your reads from.
>
> My intent was to mount the snapshot ro,noatime and operate on that.
> Am I again missing something stupid?

Hm.  No, I don't think so.  I wonder -- will the snapshot management code
cause the resulting snapshot to be in a consistent state so access through
the filesystem is safe?

Thor

Greg Troxel | 11 Jun 2012 19:18

Picon

Re: selectively disabling atime updates?

Thor Lancelot Simon <tls <at> panix.com> writes:

> On Mon, Jun 11, 2012 at 05:52:27PM +0200, Edgar Fu? wrote:
>> > Yes, but I have to question whether and why it would improve performance
>> > in this case.  The stream of atime updates is still happening on the
>> > underlying filesystem, and that is still where you will be doing almost
>> > all of your reads from.
>>
>> My intent was to mount the snapshot ro,noatime and operate on that.
>> Am I again missing something stupid?

You should only need ro; it doesn't make sense to talk about atime
updates or not when you aren't writing to the underlying block device.

> Hm.  No, I don't think so.  I wonder -- will the snapshot management code
> cause the resulting snapshot to be in a consistent state so access through
> the filesystem is safe?

I would say that it should or it's a bug; it seems the whole point of
snapshots is to get a consistent view of a filesystem.
Given that the normal use case seems to be things like
snapshot/dump/drop-snapshot, I would think that if it were buggy there's
a decent chance there would have been complaints by now.

Manuel Bouyer | 11 Jun 2012 20:25

Re: selectively disabling atime updates?

On Mon, Jun 11, 2012 at 01:18:17PM -0400, Greg Troxel wrote:
> 
> Thor Lancelot Simon <tls <at> panix.com> writes:
> 
> > On Mon, Jun 11, 2012 at 05:52:27PM +0200, Edgar Fu? wrote:
> >> > Yes, but I have to question whether and why it would improve performance
> >> > in this case.  The stream of atime updates is still happening on the
> >> > underlying filesystem, and that is still where you will be doing almost
> >> > all of your reads from.
> >>
> >> My intent was to mount the snapshot ro,noatime and operate on that.
> >> Am I again missing something stupid?
> 
> You should only need ro; it doesn't make sense to talk about atime
> updates or not when you aren't writing to the underlying block device.
> 
> > Hm.  No, I don't think so.  I wonder -- will the snapshot management code
> > cause the resulting snapshot to be in a consistent state so access through
> > the filesystem is safe?
> 
> I would say that it should or it's a bug; it seems the whole point of
> snapshots is to get a consistent view of a filesystem.
> Given that the normal use case seems to be things like
> snapshot/dump/drop-snapshot, I would think that if it were buggy there's
> a decent chance there would have been complaints by now.

You can test with fsck_ffs -X; I use it from daily scripts on some systems,
and it does the job.

--

--

(Continue reading)

J. Hannken-Illjes | 11 Jun 2012 22:01

Picon

Picon

Re: selectively disabling atime updates?

On Jun 11, 2012, at 8:25 PM, Manuel Bouyer wrote:

> On Mon, Jun 11, 2012 at 01:18:17PM -0400, Greg Troxel wrote:
>> 
>> Thor Lancelot Simon <tls <at> panix.com> writes:
>> 
>>> On Mon, Jun 11, 2012 at 05:52:27PM +0200, Edgar Fu? wrote:
>>>>> Yes, but I have to question whether and why it would improve performance
>>>>> in this case.  The stream of atime updates is still happening on the
>>>>> underlying filesystem, and that is still where you will be doing almost
>>>>> all of your reads from.
>>>> 
>>>> My intent was to mount the snapshot ro,noatime and operate on that.
>>>> Am I again missing something stupid?
>> 
>> You should only need ro; it doesn't make sense to talk about atime
>> updates or not when you aren't writing to the underlying block device.
>> 
>>> Hm.  No, I don't think so.  I wonder -- will the snapshot management code
>>> cause the resulting snapshot to be in a consistent state so access through
>>> the filesystem is safe?
>> 
>> I would say that it should or it's a bug; it seems the whole point of
>> snapshots is to get a consistent view of a filesystem.
>> Given that the normal use case seems to be things like
>> snapshot/dump/drop-snapshot, I would think that if it were buggy there's
>> a decent chance there would have been complaints by now.
> 
> You can test with fsck_ffs -X; I use it from daily scripts on some systems,
> and it does the job.

(Continue reading)

Return

Return to gmane.os.netbsd.devel.kernel.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane