From: "Carl Rueder" <carl.rueder@...>
Subject: Re: [Iscsitarget-devel] Write caching - subjective summary
Date: Wed, 27 Oct 2004 14:35:16 +0200 (MEST)
> > Please read Stephen Lord's mail more carefully. He said that
> > write back may corrupt file system metadata.
> Did I ever ignored this?
> c) Operating write back caching without battery backup was always a
Modern journaling file systems are safe with write-back without reorder.
FYI, you want to protect not only metadata but also file-data, use a
journaling file systems which logs everything.
> > Note that he said that write-back may corrupt file system metadata,
> > however, write-back preserves the ordering is safe for modern
> > journaling file systems, I think.
> That's the reason why some people implemented write barriers for io &
> filesystems (see the current kernel 2.6). To ensure transaction isolation on
Have you read my mails?
I said that ext3 uses BIO barrier to work with write-back with
reordering and it was done this summer. And I also said that reiserfs
can handle write-back with reorder. And I know how Linux I/O
architecture has evolved.
You don't need to teach me such stuff.
> > Please don't insult file system developers by saying that they are
> > crap. Your theory says that ext3 was crap (I showed you Stephen
> > C. Tweedie's mail) and XFS was crap (I showed you Stephen Lord's
> > mail). Note that you thought that XFS is designed to handle write-back
> > with reorder.
> If a filesystem has a problem with write caching it's imho buggy. That's my
So you think that XFS in Linux is buggy (at least, it was buggy in the
past due to the developer's mail). And you thought that it is designed
for enterprise use.
> opinion. Why was write barrier support developed? Why not just forcing write
If a disk drive, that uses write-back with reorder, cannot flush disk
cache in the presence of a system crash, it is evil for file systems.
However, as I said, some file system developers started to work on
this issue. That's why write barrier support was developed. But it
takes a long time. You quoted Linus's mail (2001) and some of file
systems in Linux have supported this since 2004.
So you call the file systems, which cannot handle write-back issue,
crap, it's wrong.
> > You don't know anything about file systems and Linux I/O design. Why
> > are you so rude?
> Why am I rude? Why are you so focused on only ext3 and Linux?
How do you think about people who say that something is crap without
knowledge about it?
How do you think about people who critisize developers without
knowledge about their work?
If they are not rude, who is rude?
And when I said that some file systems in Linux, like XFS and JFS,
can't handle "write back with reorder",
You replied, "I just won't believe that current file systems are such
a misdesign." even though you don't know anything about file system
implementations in Linux. So I looked for XFS developer's mail saying
that write-back cache may destroy your file system. Why did I do
such things to correct you? You should have done this for yourself.
Isn't it rude to deny someone's opinion without any knowledge and
waste his time to correct your misunderstanding?
Note that it is possible that XFS developers had worked this issue. So
please correct me by asking the developers if I'm wrong.
> > Don't insult or criticize people by only your assumption. As I
> > showed, you know no truth about file system implementations.
> I assume I know as much about linux filesystems as you know about
> commercial systems. I don't claim to know everything, do you?
I don't know anything about commercial systems, so did I criticize
them by calling them crap like you?
> > You don't need to say "You have to do something.". You have to do what
> > you want for yourself.
> Unfortunately I dont have too much programming experience on kernel layer
> but I have some experiences on storage, storage area networks, databases and
> other commercial systems used for handling real workload. But if you don't
> need such experience I won't bother here anymore.
Please don't bother me any more.
> > If IET is not useful for you, please go away and find another solution.
> Isn't your objective the development of an "iSCSI target with professional
> features, that works well in enterprise environment under real workload, and
> is scalable and versatile enough to meet the challenge of future storage
> needs and developements" anymore?
> I only wanted a constructive discussion about improvements to write caching
I don't think so.
For example, I explained one of reasons why it is difficult to achieve
write-back policy in IET, which disk drives provide. I don't think
that your reply was constructive.
I love to listen to users' opinions and collaborate with
people. However, I don't think that I can work with you
constructively, though I'm not sure about how other people feel.
All I can say is that please go away and find another solution.