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) b
> 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 op
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 - hann...@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
> 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
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
> 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 WA
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
snapsho
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!
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
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
> 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.
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 sn
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 n
> 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
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
> 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
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
> The problem is that the `read-only' device is changing
> behind the filesystem's back.
Ah, yes, of course. Stupid me!
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 you
Thor Lancelot Simon 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
On Mon, Jun 11, 2012 at 01:18:17PM -0400, Greg Troxel wrote:
>
> Thor Lancelot Simon 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
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 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
>>>
> 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_BETAJanuary 31, 2005NetBSD 6
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
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 th
25 matches
Mail list logo
