on line file system size increase?

[joseph pareti]

Hi,

I am responding to a customer’s RFP on a HA solution for database, and we would like to compare a linux based solution to an hp-ux based one.

In particular the following is required of the volume manager/file system:

For the future solution we need performance, stability and scalability. On all systems we need being able to enlarge and reduce file systems on line and without data loss. For this purpose we need a robust Logical Volume Manager solution. It is mandatory to use a robust and efficient file system that supports large files, on line de-fragmentation and is equally efficient with large and small files. In addition we need a journaling capability to avoid fsck after reboot, and that at least completes the check very fast for file systems in the terabyte-range.

Would that be feasible under Linux? Any further advise?

TIA

[Steven E. Protter]

Shalom,

Red Hat 4 and below ships with online2fs. This will allow you to resize file systems without umount and costs nothing extra.

In RHEL 5 that was replaced with resize2fs which as the exact same syntax, abilities and functionality.

As far as defrag goes, ext3 the filesystem of Linux does not fragment much and no defrag tools are provided.

You can with downtime occasionally copy all files off a file system, copy them back and that does defragment, though there is little marginal improvement in performance.

There is no hot, online replacement for fsck in any Linux distribution. If a problem requires fsck, the file system MUST be umounted prior to check. There is no equilvalent tool for HP-UX either, though OnlineJFS will handle defragmentation on that OS.

SEP

[Mike Stroyan]

Reducing the size of online filesystems is extremely rare. You can see the short list of them by looking at the "Online shrink" column at http://en.wikipedia.org/wiki/Comparison_of_file_systems#Features .
There are only four listed there as known to be able to do that.

[joseph pareti]

Perhaps I should better explain one of the points in enclosure "In addition we need a journaling capability to avoid fsck after reboot, and that at least completes the check very fast for file systems in the terabyte-range."

What I meant is that they want a JFS in Linux to optimally avoid file system check upon reboot after a crash; and if this functionlality is not fully available they want at least a very efficient way to recover file systems that are > 1TB in size.