[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Martin Husemann wrote:
> On Thu, Jul 31, 2008 at 01:52:04PM -0400, Perry E. Metzger wrote:
> > 2) Is there any advantage to allocating a log after the partition
> > rather than within the file system?
> Don't think so, but there is no disadvantage either - so if you have already
> newfs'd before the in-filesystem log support turned up, there is no need
> to re-newfs now. If you have no log, just use the in-filesystem log area.
Possibly the only advantage of an end-of-partition log is with
removable media or in the case where you might possibly boot an older
kernel/userland that doesn't know about the log. In this case, the log
at the end of the filesystem won't confuse an older kernel and fsck_ffs
as much. I'm about to post something to tech-kern about this.
An in-filesystem log might just have some performance benefit in that
you don't need to seek as far on average when flushing and reading from
the journal, but Darrin suspected that the fact you needed to seek
anyway was the overriding factor, and how far you had to see wouldn't
make too much of a difference. Note that this hasn't been benchmarked
> > 3) Is there a reason that the journal is limited to 64M?
> The journal is metadata only, and 64 M is quite a bit of metadata. I think
> Solaris uses the same scaling. IIUC this limit is only the autoscaling, you
> can assign bigger values via tunefs.
This is correct.
Main Index |
Thread Index |