From: clflush <clflush@chello.be>
To: Taisuke Yamada <tyamadajp@list.rakugaki.org>
Cc: xfs@oss.sgi.com
Subject: Re: Questions about XFS
Date: Thu, 15 Mar 2007 10:07:32 +0100 [thread overview]
Message-ID: <200703151007.32630.clflush@chello.be> (raw)
In-Reply-To: <45F8CAEA.3050408@list.rakugaki.org>
>From what I know, and correct me if I'm wrong, XFS relies on the application
side to do the right job but real world experience shows us that *a lot* of
applications out there behave badly and cannot be trusted hence if something
happens, XFS cannot "correct" the problem leaving you with headaches behind
depending on how much data you lost/corrupted and the importance of it. IMHO,
XFS *should* do some effort at assuring integrity to minimize the bad
behavior of badly written applications out there. I know that XFS wasn't
written for PC class hardware in the first place, but most people do not read
enough to understand XFS and use it on their desktops/laptops because to be
honest Linux doesn't really have a good file system, and XFS out of all
available file systems, is the best in performance and scalability terms.
On the one hand you have the old Ext3 FS which doesn't perform very well in
many areas but IMO is a lot safer to work on (doesn't loose data that easily
compared to XFS - and I'm talking from experience here because I use both
file systems and I lost much more on the XFS system than on the Ext3 one) and
on the other hand you have this excellent XFS file system with its clean
layout and awesome performance + fancy features like GRIO, extents, allocate
on flush, real time volumes, etc *but* is not "safe" enough to work with if
you have unreliable hardware and/or a lot of power outage issues - I've
never lost data on Ext3 during a power outage but already lost 2 times data
on XFS
Just my $0.02
On Thursday 15 March 2007 05:26:18 you wrote:
> From end-user's POV, this infamous XFS behavior is somewhat
> taken as XFS's inferiority compared to other filesystems.
> Even with "bad" applications (ex. firefox), this rarely happens
> on others, so regardless of what's on the FAQ, people logically
> concludes that the fault belongs to XFS anyway.
>
> So, what is the correct way to do IO?
> Is what firefox (and other bad apps) doing is so obvious(ly buggy),
> that it'll be acknowledged as a bug once reported? Or is it simply
> a mismatch between application expectation and XFS behavior,
> requiring a non-(obvious|generic) fix?
>
> Although I'm not a filesystem developer, I'm pretty impressed with
> XFS and willing to file a report/patch to those "buggy" apps if the
> issue is explainable to other app developers.
>
> >> was to press the reset button on the computer. After the reboot, when I
> >> opened Firefox again, I noticed that all my bookmarks were gone. Those
> >> bookmarks were imported from my desktop machine a few days after I
> >> configured the new server.
> >
> > This is a firefox bug - I've seen it before (on my mother's machine).
> >
> > It's due to firefox not doing the correct thing with IO on the bookmarks
> > file.
next prev parent reply other threads:[~2007-03-15 9:07 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 13:40 Questions about XFS clflush
2007-03-13 15:36 ` Klaus Strebel
2007-03-13 15:53 ` Stein M. Hugubakken
2007-03-13 15:55 ` Eric Sandeen
2007-03-14 16:33 ` Stewart Smith
2007-03-15 4:26 ` Taisuke Yamada
2007-03-15 9:07 ` clflush [this message]
2007-03-15 14:41 ` Geir A. Myrestrand
2007-03-16 10:36 ` Martin Steigerwald
2007-03-17 0:47 ` Jason White
2007-03-29 15:07 ` cache flush support in SATA drives (was: Re: Questions about XFS) Martin Steigerwald
-- strict thread matches above, loose matches on Subject: below --
2013-06-11 9:56 Questions about XFS Steve Bergman
2013-06-11 13:10 ` Emmanuel Florac
2013-06-11 13:35 ` Stefan Ring
2013-06-11 13:52 ` Ric Wheeler
2013-06-11 13:59 ` Ric Wheeler
2013-06-11 16:12 ` Steve Bergman
2013-06-11 17:19 ` Ric Wheeler
2013-06-11 17:27 ` Stefan Ring
2013-06-11 17:31 ` Ric Wheeler
2013-06-11 17:41 ` Stefan Ring
2013-06-11 18:03 ` Eric Sandeen
2013-06-11 19:30 ` Steve Bergman
2013-06-11 21:03 ` Dave Chinner
2013-06-11 21:43 ` Steve Bergman
2013-06-11 17:59 ` Ben Myers
2013-06-11 17:28 ` Eric Sandeen
2013-06-11 19:17 ` Steve Bergman
2013-06-11 21:47 ` Dave Chinner
2013-07-22 14:59 ` Steve Bergman
2013-07-22 15:16 ` Steve Bergman
2013-06-12 8:26 ` Roger Oberholtzer
2013-06-12 10:34 ` Ric Wheeler
2013-06-12 13:52 ` Roger Oberholtzer
2013-06-12 12:12 ` Stan Hoeppner
2013-06-12 13:48 ` Roger Oberholtzer
2013-06-13 0:48 ` Dave Chinner
2013-06-11 19:35 ` Ben Myers
2013-06-11 19:55 ` Steve Bergman
2013-06-11 20:08 ` Ben Myers
2013-06-11 21:57 ` Matthias Schniedermeyer
2013-06-11 22:18 ` Steve Bergman
2013-10-25 14:28 harryxiyou
2013-10-25 14:42 ` Emmanuel Florac
2013-10-25 14:57 ` Eric Sandeen
2013-10-25 16:24 ` harryxiyou
2013-10-25 16:44 ` harryxiyou
2013-10-26 10:41 ` Stan Hoeppner
2013-10-27 3:29 ` Eric Sandeen
2013-10-25 16:13 ` harryxiyou
2013-10-25 16:16 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200703151007.32630.clflush@chello.be \
--to=clflush@chello.be \
--cc=tyamadajp@list.rakugaki.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox