XFS does not put data into the log. It keeps track of meta-data operations
in the log. One goal of XFS is to remove the need for fsck at start-up.
This is a very big deal when one has very large file systems. fsck can
take a very long time on very large file systems.
If you are looking for a file system that logs data, XFS is
not your solution. XFS does allow a file to be written synchronously
with O_SYNC so you can guarantee that the data is on disk
when the write returns.
There is much more to XFS than the log and journalling.
Saying that because XFS doesn't log data, it is no better than NTFS
doesn't address all the other aspects of XFS.
Have you seen the latest XFS white paper? The current one off of SGI's
web page is pretty old. The latest paper compares NTFS, XFS,
VxFS and is a pretty good overview of XFS. XFS has had more
stuff added to it in recent months (like a new defag tool)
which is not in the paper.
I just looked around and I don't see a publicly available web
jumper for it. We'll set one up and I'll send it around next
week.
Jim
>
>
>Jim,
>
>Some journal based FS's will serialize reads when A) there is cached data
>(in a buffer cache for example), and there is a requirement for writes to be
>committed real time with reads always having the most current data, and B)
>when transactioning is implemented above the FS and you have writes and
>reads to the same block (do you return the stale data, or do you return the
>write that was posted to the journal and cached, but not yet committed?) In
>theory, you could avoid serializing on reads, but you may get stale data.
>
>This applies to journalled FS's that post both user data and meta data to
>the log file. NTFS, for example, only posts meta data to the log file for
>restart, and does not post user writes to the journal. This means you can
>lose user data on a restart. If XFS is only writing meta data to the
>journal, and not user data, as you suggest, then you are technically correct
>that reads do not have to be serialized, however, this also means that XFS
>is not a **TRUE** journalling file system because you can lose user data on
>restarts, and the benefits it provides for journalling are not much better
>than running "fsck" after a system crash.
>
>Surely this is not the case -- this would mean that XFS is no better than
>NTFS.
>
>Jeff
>
>----- Original Message -----
>From: Jim Mostek <mostek@sgi.com>
>To: Andreas Bogk <andreas@andreas.org>
>Cc: <jmerkey@timpanogas.com>; <mcai7et2@stud.umist.ac.uk>;
><linux-kernel@vger.rutgers.edu>
>Sent: Friday, May 28, 1999 8:58 AM
>Subject: Re: XFS and journalling filesystems
>
>
>> >feature for video: guaranteed bandwidth. Also, journalling slows down
>> >reading, but speeds up writing, which is again important for
>> >video. So, as long as ext3 is not there, I'll be very happy about XFS.
>>
>> How does journalling slow down reading? The only time XFS needs
>> to create a transaction is when changing meta-data (like a create,
>> file extend, remove, ...).
>> XFS doesn't do transactions for time updates. Do other FSs?
>> XFS doesn't do transactions on writting if the file is already
>> allocated.
>>
>> Jim
>>
>> >
>> >Andreas
>> >
>> >--
>> >Reality is two's complement. See:
>> >ftp://ftp.netcom.com/pub/hb/hbaker/hakmem/hacks.html#item154
>> >
>> >-
>> >To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>in
>> >the body of a message to majordomo@vger.rutgers.edu
>> >Please read the FAQ at http://www.tux.org/lkml/
>> >
>>
>>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/