On Wed, 2007-08-29 at 14:39 -0400, Justin Bronder wrote:
> Greetings,
> 
> Forgive me if this has already been answered in the past, but a
> cursory glance through the archives didn't turn up much.
> 
> I'm interested in the real dangers of mounting with nointegrity.
> Currently I am working with an application which dumps a large
> amount ( 5-7 GB) of data to a jfs filesystem (backed by two disks
> using md RAID 0).  Once the data is written, a later process will
> come in and process it, moving the relevant parts to another
> filesystem.
> 
> Using /proc/sys/vm/block_dump, I monitored the access pattern
> to the device.  When making a default jfs filesystem and
> mounting only using noatime, I get three sections of the disk
> written to.  The most frequent is obviously the data, which slopes
> upward slowly.  I also saw quite frequent writes to a sector near
> the beginning of the data slope, and less frequent writes to a
> sector far above the end of the data.
> 
> By pushing journaling to an external device, I removed the top
> and least frequent pattern.  If I mount with nointegrity, I get
> just the data slope, with a quick hit to the beginning of the
> slope every ~1.2 seconds, compared to clumps of writes
> occurring less than ~0.3 seconds apart.
> 
> As I am looking to maximize the performance of the disks during
> the dumping of this data, I'm obviously slightly concerned about
> the time it's taking to seek across the disks, and mounting with
> nointegrity seems to be a decent solution.  Given that we'll be
> processing the data fairly soon after, and the processing won't
> happen if another large write is taking place, I'm wondering how
> risky it would be to either:
> 
> a.) Mount the filesystem with nointegrity and leave it like that.
> If the file has been opened, written to, and closed, do we stand
> to lose anything should a power loss happen later?

If the power loss happens after a period of inactivity, you're probably
pretty safe, but there is no guarantee.  If a power loss occurs while
the file system is being written to, or very shortly after, before all
the data is flushed to disk, you could lose data.

> b.) Mount the filesystem as nointegrity for the duration of the
> large write, then remount with integrity immediately afterwards.
> Is there any risk when remounting the filesystem a large number
> of times in this fashion?

This would minimize the risk.  The file system integrity would only be
compromised while the file system is mounted with nointegrity.

The motivation for nointegrity was to allow faster restores from backup
media, such that if a power loss occurred, the file system could be
re-formatted and the process could be restarted.  There really are no
guarantees of what can be recovered if a power loss (or system crash)
occurs during a nointegrity mount.

If you use a dedicated file system, that contains no other data, and if
the process of dumping the data to the jfs volume is restartable,
nointegrity would be a good option for you.
-- 
David Kleikamp
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion

Reply via email to