Raw Disk Vs Filesystem

[Karthik S S]

Hi,

Could anuyone explain me why Raw partition is better than filesystems -- pro and cons. Also,
-How do I access individual files that are stored on raw partition. ( with FS it is easy bcoz we have a mount point and tree structure)
-What is the equivalent of fsck for raw partitions?


Thanks
Karthik

[avsrini]

Hi Karthik,

Raw partition is accessed in character mode, so IO is faster than fs partition which is accessed by block mode. with raw partitions you can do bulk IO's.

Raw partitions are generally used for databases by RDBMS softwares.

You cant access individual files from raw partition. Because files stored in raw partitions are managed by the softwares that use that. OS does'nt know what is stored on this partition.

Srini

[Michael Tully]

Raw is generally considered faster because it is not buffered by the operating system. Under some cirimstances raw can result increased performance.

Some RDBMS systems prefer raw, like Informix some like Oracle prefer filesystems. You can't actually address files on a raw partition. These are done through an RDBMS interface.
There is no 'fsck' equivalent. The best way to prevent corrupted data is to make sure that databases are shutdown correctly prior to any system maintenance that may require any sort of outage.

[Yogeeraj_1]

hi karthik,

Raw Logical Volume is an area of physical and logical disk space that is under the direct control of an application rather than under control of the operating system and file system. The applications use character (raw) input and output rather than the block input and output of file systems, which require more software overhead. Bypassing the file system overhead enables applications to perform better. Raw logical volumes are most commonly used with database applications because of their need for high performance. While there is ordinarily a significant increase in performance, the actual amount of the increase depends on the database size and the driver provided by the application.

hope this helps!
Best Regards
Yogeeraj

[Ravi_8]

Hi,

Raw devices gives better performance compared to file syetm, since in raw devices data is read/written in characters whereas in file system it is in blocks

[Ravi_8]

Hi,

Raw devices gives better performance compared to file syetm, since in raw devices data is read/written in characters whereas in file system it is in blocks.

you can't access files on raw devices and also can't do fsck.

due to these difficulties with Raw devices all the OS's uses file systems

[Dave Wherry · Accepted solution]

The raw versus "cooked" debate has been around for a long time. Your database vendors would always tell you to use raw for the afore mentioned reasons. Mostly for bypassing the system buffer cache. Most of this goes all the way back to hard partitioned disks.

Since LVM, JFS, Veritas.... it's not as cut and dried as it used to be. You can mount your file systems where they bypass system buffer cache and you are no longer affected by the double cache hit of data having to go through the RDBMS cache and the system buffer cache. Having your database on "cooked" file systems allows you some better management and monitoring of those file system over raw partitions. Can be just a little easier to work with.

It can probably be argued that the raw volumes will still give better performance than file systems. It's just not as dramatic or significant as it used to be. If you need to squeeze every last bit of performance go raw. With the amount of cache that can be configured, especially with 64 bit systems and applications, the speed of drives and controllers and the cache in drive arrays, databases mounted on file systems perform pretty well.

[Steven E. Protter]

Software AG adabase as an example has much, much better throughput on a raw disk partition than a filesystem.

It depends on how the application was was engineered.

Oracle version 8 and below always ran better on a normal vxfs filesystem under HP-UX.

I am told though that Oracle 9i Release 2 has changed this situation and only runs on raw partition under HP-UX.

So in many ways, the answer is "it depends" In most cases with this question, it depends on the application vendor.

I personally find filesystems easier to clean up and manage, but the problem is people dump stuff that doesn't belong on them, clogging them up.

One really big advantage of raw disk partitions is they are not visible to regular users. You can't copy a file to them with a cp command.

SEP

[A. Clay Stephenson]

Unlike many others, I actually take the time to measure this stuff and the bottom line is on newer versions of HP-UX there is almost no measurable difference between raw disk and the equivalent OnlineJFS mount options that bypass the buffer cache. Moreover, there is every reason to use LVM raw volumes vs physical raw volumes because the LVM overhead is so small. It's basically one extra indirection in the device switch table. I also could not see a raw/io vs. cooked files improvement in Oracle 9i though I admit I have not extensively tested it. For my applications, the cooked files
won on 9i/11.11.

Nowadays, in my humble opinion, the only reason to ever use raw/io is in the case of multiple hosts accessing the same data - you can't do that with filesystems because systemA has no idea what is happening in systemB's buffer cache.

A question about fsck and raw partitions is absolutely meaningless. There is no underlying structure to a raw partition. From the view of the host, it's simply a contigious bunch of disk blocks. You can dd it to look for bad disk blocks but that's it.

[Sridhar Bhaskarla]

Hi Karthik,

The answer is it depends. The general perception is that raw partitions perform better. But I have seen applications gaining from the buffer cache too.

While your questions have been already answered, I would add the you try onlineJFS's mount point options. If your application does not benefit from the buffer cache, you can still have it on cooked filesystems and bypass buffer cache. Use mincache=direct (for asynchronous) and convosync=direct (for synchronous) options along with delaylog. This is a win-win situation for you.

-Sri