> Quoting Steve Lord <lord@xxxxxxx>:
> > An external log is growable, an internal one unfortunately is not, and
> > we keep kicking SGI support people who build multi-terabyte filesystems
> > without reading the man page.
> >
> > Unless you specified otherwise you have two logbufs, all you need to do
> > to get the number changed is remount with the new option, so yes, edit
> > fstab and reboot.
>
> Does mkfs default to create one or two logbufs? If it default to creating one
> ,
> I presume that it creates an external log which you can then grow using the
> mount option? Is an internal logbuf much better (performance wise) compared t
> o
> an external logbuf (I presume this, but ask anyway).
You have your terminology crossed, logbufs are in memory buffers the number
of which is configurable at mount time, they basically represent the
number of buffers which can be in flight on their way to the on disk
log at once. If you have more you can sustain a higher transaction rate
without having to block waiting for a previous log write to complete.
The log itself is constructed at mkfs time, and comes in two flavors,
internal and external. The internal log is basically in the middle of
the partition/volume which forms the filesystem and cannot be extended
after mkfs. The external log is in theory easier to extend, and can
certainly be on a device with different characteristics (e.g. an NVRAM
disk). At the moment we do not really have the tools to extend this
either, but the procedure I described could be used.
The advantage of the internal log is you do not need anything more than
a regular partition, it is the default. The external log takes a little
work to setup (second device specified at mkfs time) and use (logdev=xxx)
option at mount time, but is more flexible (there is no conflict between
moving the head for the log and the data). Irix volume managers support
having multiple 'subvolumes' within a volume, so mkfs and the kernel can find
the log for themselves without the extra options.
>
> Maybe we can include this in the FAQ together with the current entry about th
> e
> mount options? Or is the presence in the man page good enough? :)
>
> > If you use O_SYNC anywhere then osyncisdsync as a mount option will
> > make xfs O_SYNC behave more like other linux filesystems.
>
> I'm a total ignoramus (;>) when it comes to these nitty-gritties about
> filesystem operation, but in a nutshell maybe we can have information about t
> he
> consequences of this (aside from the already stated speed benefit) on the
> reliability of the data? When is O_SYNC normally called and what does O_DSYNC
>
> do in comparison with O_SYNC that will make it I/O sync less? :) :)
>
> Thanks a lot for this tweaking help. :)
O_SYNC is used when you want to know on return from a write system call
that the data you wrote will still be there after a crash. A mail program
might use it when appending to a mailbox before removing the mail from
the queue for instance.
O_SYNC will always do a synchronous transaction to write out the inode to
the log at the end of the write, it does this to guarantee the timestamps
are recorded. O_DSYNC (on Irix) or the osyncisdsync mount option on linux
will only log the inode if the size was changed by the write. The act
of flushing this transaction to the log means all previous transactions
which are still in memory for the inode are also flushed and hence safe
from crash. In both cases the data is flushed.
Steve
>
> --> Jijo
>
> --
> Federico Sevilla III :: jijo@xxxxxxxxxxxxxxxxxxxx
> Network Administrator :: The Leather Collection, Inc.
|