Hi!                                            

I am concerned about the discussion climate here on this list.  


You,Carl, said:
 "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.
"

Fine, we need all experience there is out there! But why don´t offer it to us in a little bit humble way, not try to force your solutions on us?

 It seems to me, that you need iet so badly, and the way you want it, that you try to force the developers to go your way.

 You also seem to have all the answers, and on everything. I have difficulties to trust people who have all the answers.  

 We want a nice and constructive discussion climate on the list, and if you can live with that, please be wellcome to join us. But if you need to bulley us around, do it some other place!


              Best regards from/Med vänliga hälsningar från

                                Johan Kragsterman


        Co-Founder and administrator of IET Group

                              http://www.capvert.se



"Carl Rueder" <carl.rueder@gmx.net>
Sänt av: iscsitarget-devel-admin@lists.sourceforge.net

2004-10-27 14:35

       
        Till:        FUJITA Tomonori <tomof@acm.org>
        Kopia:        iscsitarget-devel@lists.sourceforge.net
        Ärende:        Re: [Iscsitarget-devel] Write caching - subjective summary



> Please read Stephen Lord's mail more carefully. He said that
> write back may corrupt file system metadata.

Did I ever ignored this?

> 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
IO.

> Why is it so difficult for you to understand the fact that some
> journaling file systems in Linux don't support write back caching with
> reordering?

Why is it so difficult for you to see that there are some other systems
beyond Linux doing the things right? You want to provide a target, not an
initiator!

What are the facts (from my point of view):
1) Some filesystem are having problems with reordering
2) Some filesystems aren't having any problems with reordering
3) Harddisks are doing reordering
4) Write through cuts real database workload performance down to 20%

> 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
opinion. Why was write barrier support developed? Why not just forcing write
through?

> 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?

> Again, how could you said such thing even though you don't know
> anything about XFS and ext3 implementations in Linux.

Sure, reordering was an issue, but now there are solutions. It won't improve
IET any further if we dispute on past issues.

> I think that you have some experience and read white papers about
> these file systems, however, how can you be sure that they are
> true? You can find truth only in the source code.

Why do I have to take care only for these filesystems? Why should I ignore
other implementations?

> 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?

> 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.

> 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
but your only arguments were the handicaps of some Linux filesystems. If you
don't want to get feedback from users who are having experience in real
workload systems, ok, no problem. But don't expect to play in the enterprise
league. Your highest scoring will be the toys club. Just my few cents.

Bye
Carl

--
Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD
++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel