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? 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? Thanks, Justin ------------------------------------------------------------------------- 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
