great, another write back fellow ;-)
Currently, I don't understand the IET code nor do I know too much about the
linux io layer. But I'm deep into SCSI now and will do what I can do for
further development of IET write back. If I understand the current
implementation right, we have a SCSI interface to the initiator and a
file-handle to the storage, right?
On the SCSI side, all mandatory commands for random access devices has to be
* The target should present itself as unqueued or untagged queued device,
never as tagged queued so we don't have to implement queue commands.
* The target must honor the FUA & DPO bits in READ & WRITE commands (r/w
* The target must honor the SYNCHRONIZE CACHE command. For simplification we
could flush the whole cache, not only the requested regions.
On the file side we must check how we can doing buffered & unbuffered writes
on it. I assume the remaining IO layer (SCSI/IDE/whatever) is supporting
write through and write back, but I'll check it. Maybe I'll find something
about the previously discussed write barrier in the kernel.
If someone could give me a brief explanation of the different source files
and their task I might understand the code the next days :-)
----- Original Message -----
From: "Brian Wolfe" <brianw@...>
To: "Carl Rueder" <carl.rueder@...>
Cc: "iet-dev" <iscsitarget-devel@...>
Sent: Tuesday, October 26, 2004 8:01 PM
Subject: Re: [Iscsitarget-devel] Write caching
> It would seem that IET needs to support write-back caching if the users
> request it (obviously this is dependant on a:volunteers coding it or b:
> the main developers having the time/desire).
> Me, I'm willing to give it a try with the minimal spare time that I
> have. I'll probably need to pester someone that has good knowlege of
> SCSI commands and whatnot to ensure I don't royally fsck things up. ;)
> I have noticed one nice thing about using IET on a unprived domain that
> mounts partitions from another prived domain on a xen box. It seems to
> introduce *some* buffering. The disk traffic of the domain-0 (handles
> the real interface to the ide disks and raid-5) doesn't really match up
> with the IO traffic in the IET domain (takes virtual disks shared by
> domain-0 and exports them as iscsi targets). This is leading me to
> believe that under xen, it's reordering some things.
> Note, I have no proof, it may not even be intentional, but running
> things this way under xen tends to speed up random seeks for reads and
> writes a bit vs a native linux machine. I'll see if I can't figure out
> exactly why this happens and report back if anyone is interested. As a
> side note, I've never had any nasty corruption of my reiserfs partitions
> due to rare crashes (these are all dev type systems). Just the typical
> data not written, but journals were just fine type corruption which
> reiserfs handled just fine. :)
> *warnign, rant follows*
> This, and Linus' words, tells me that we really shouldn't take up the
> job of the filesystem to ensure that data makes it to the disk in the
> right order, or even the possibility that a crash will cause it's loss
> compeltely (as long as it's not IET that's crashing the system. ;) ).
> The tools are there. If the filesystem driver doesn't make use of them
> properly, it isn't IET's job to take up the slack in safety IMHO. By
> providing write-through ONLY, IET has met the minimal requirements IMHO,
> as has no more responsibility beyond them. Anything else is at the
> team's option (or the users option to submit a patch for).
> Back to who implements and when. If the main IET developers don't want
> to implement write-back caching, hey, that's their decision on where IET
> will progress. I as a user *must* respect that and be willing to get my
> own hands dirty with kernel code if I want the feature. This *IS* after
> all a GPLd Open Source project. ;)
> so, quit your bitching if the IET guys don't want to tackle this feature
> yet. It's not mandatory for IET to do what it says it does. If you want
> it, go write it, or wait patiently. cryign that it'll "go nowhere" won't
> change their minds in all likelyhood if all you do is rant and rave
> about wanting it.
> *rant over*
> whew. Sorry that it's a long one guys. :)
> On Tue, 2004-10-26 at 12:26, Carl Rueder wrote:
>> Interesting words from Linus :-)
>> 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.
>> Iscsitarget-devel mailing list