From: "Moore, Eric" <Eric.Moore@lsi.com>
To: ric@emc.com, Alan <alan@lxorguk.ukuu.org.uk>
Cc: Theodore Tso <tytso@mit.edu>, Neil Brown <neilb@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Linux-ide <linux-ide@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-raid@vger.kernel.org, Tejun Heo <htejun@gmail.com>,
James Bottomley <James.Bottomley@SteelEye.com>,
Mark Lord <mlord@pobox.com>, Jens Axboe <jens.axboe@oracle.com>,
"Clark, Nathan" <Clark_Nathan@emc.com>,
"Singh, Arvinder" <Singh_Arvinder@emc.com>,
"De Smet, Jochen" <DeSmet_Jochen@emc.com>,
"Farmer, Matt" <Farmer_Matt@emc.com>,
linux-fsdevel@vger.kernel.org, "Mizar,
Sunita" <Mizar_Sunita@emc.com>
Subject: RE: end to end error recovery musings
Date: Mon, 26 Feb 2007 18:10:57 -0700 [thread overview]
Message-ID: <664A4EBB07F29743873A87CF62C26D705D6DDB@NAMAIL4.ad.lsil.com> (raw)
On Monday, February 26, 2007 9:42 AM, Ric Wheeler wrote:
> Which brings us back to a recent discussion at the file
> system workshop on being
> more repair oriented in file system design so we can survive
> situations like
> this a bit more reliably ;-)
>
On the second day of the workshop, there was a presentation given by
Martin K. Petersen on Data Intergrity Feature, which is also called
EEDP(End to End Data Protection), which he presented some
ideas/suggestions of adding an API in linux for this. I have his
presentation if anyone is interested. One thing is scsi mid layer needs
32 byte cdbs support.
mpt fusion supports EEDP for some versions of Fibre products, and we
plan to add this for next generation sas products. We support EEDP in
the windows driver where the driver generates its own tags. Our Linux
driver don't.
Here is our 32 byte passthru structure for SCSI_IO, defined in
mpi_init.h, which as you may notice has some tags and flags for EEDP.
typedef struct _MSG_SCSI_IO32_REQUEST
{
U8 Port; /* 00h
*/
U8 Reserved1; /* 01h
*/
U8 ChainOffset; /* 02h
*/
U8 Function; /* 03h
*/
U8 CDBLength; /* 04h
*/
U8 SenseBufferLength; /* 05h
*/
U8 Flags; /* 06h
*/
U8 MsgFlags; /* 07h
*/
U32 MsgContext; /* 08h
*/
U8 LUN[8]; /* 0Ch
*/
U32 Control; /* 14h
*/
MPI_SCSI_IO32_CDB_UNION CDB; /* 18h
*/
U32 DataLength; /* 38h
*/
U32 BidirectionalDataLength; /* 3Ch
*/
U32 SecondaryReferenceTag; /* 40h
*/
U16 SecondaryApplicationTag; /* 44h
*/
U16 Reserved2; /* 46h
*/
U16 EEDPFlags; /* 48h
*/
U16 ApplicationTagTranslationMask; /* 4Ah
*/
U32 EEDPBlockSize; /* 4Ch
*/
MPI_SCSI_IO32_ADDRESS DeviceAddress; /* 50h
*/
U8 SGLOffset0; /* 58h
*/
U8 SGLOffset1; /* 59h
*/
U8 SGLOffset2; /* 5Ah
*/
U8 SGLOffset3; /* 5Bh
*/
U32 Reserved3; /* 5Ch
*/
U32 Reserved4; /* 60h
*/
U32 SenseBufferLowAddr; /* 64h
*/
SGE_IO_UNION SGL; /* 68h
*/
} MSG_SCSI_IO32_REQUEST, MPI_POINTER PTR_MSG_SCSI_IO32_REQUEST,
SCSIIO32Request_t, MPI_POINTER pSCSIIO32Request_t;
WARNING: multiple messages have this Message-ID (diff)
From: "Moore, Eric" <Eric.Moore@lsi.com>
To: <ric@emc.com>, "Alan" <alan@lxorguk.ukuu.org.uk>
Cc: "Theodore Tso" <tytso@mit.edu>, "Neil Brown" <neilb@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"Linux-ide" <linux-ide@vger.kernel.org>,
"linux-scsi" <linux-scsi@vger.kernel.org>,
<linux-raid@vger.kernel.org>, "Tejun Heo" <htejun@gmail.com>,
"James Bottomley" <James.Bottomley@SteelEye.com>,
"Mark Lord" <mlord@pobox.com>,
"Jens Axboe" <jens.axboe@oracle.com>,
"Clark, Nathan" <Clark_Nathan@emc.com>,
"Singh, Arvinder" <Singh_Arvinder@emc.com>,
"De Smet, Jochen" <DeSmet_Jochen@emc.com>,
"Farmer, Matt" <Farmer_Matt@emc.com>,
<linux-fsdevel@vger.kernel.org>,
"Mizar, Sunita" <Mizar_Sunita@emc.com>
Subject: RE: end to end error recovery musings
Date: Mon, 26 Feb 2007 18:10:57 -0700 [thread overview]
Message-ID: <664A4EBB07F29743873A87CF62C26D705D6DDB@NAMAIL4.ad.lsil.com> (raw)
On Monday, February 26, 2007 9:42 AM, Ric Wheeler wrote:
> Which brings us back to a recent discussion at the file
> system workshop on being
> more repair oriented in file system design so we can survive
> situations like
> this a bit more reliably ;-)
>
On the second day of the workshop, there was a presentation given by
Martin K. Petersen on Data Intergrity Feature, which is also called
EEDP(End to End Data Protection), which he presented some
ideas/suggestions of adding an API in linux for this. I have his
presentation if anyone is interested. One thing is scsi mid layer needs
32 byte cdbs support.
mpt fusion supports EEDP for some versions of Fibre products, and we
plan to add this for next generation sas products. We support EEDP in
the windows driver where the driver generates its own tags. Our Linux
driver don't.
Here is our 32 byte passthru structure for SCSI_IO, defined in
mpi_init.h, which as you may notice has some tags and flags for EEDP.
typedef struct _MSG_SCSI_IO32_REQUEST
{
U8 Port; /* 00h
*/
U8 Reserved1; /* 01h
*/
U8 ChainOffset; /* 02h
*/
U8 Function; /* 03h
*/
U8 CDBLength; /* 04h
*/
U8 SenseBufferLength; /* 05h
*/
U8 Flags; /* 06h
*/
U8 MsgFlags; /* 07h
*/
U32 MsgContext; /* 08h
*/
U8 LUN[8]; /* 0Ch
*/
U32 Control; /* 14h
*/
MPI_SCSI_IO32_CDB_UNION CDB; /* 18h
*/
U32 DataLength; /* 38h
*/
U32 BidirectionalDataLength; /* 3Ch
*/
U32 SecondaryReferenceTag; /* 40h
*/
U16 SecondaryApplicationTag; /* 44h
*/
U16 Reserved2; /* 46h
*/
U16 EEDPFlags; /* 48h
*/
U16 ApplicationTagTranslationMask; /* 4Ah
*/
U32 EEDPBlockSize; /* 4Ch
*/
MPI_SCSI_IO32_ADDRESS DeviceAddress; /* 50h
*/
U8 SGLOffset0; /* 58h
*/
U8 SGLOffset1; /* 59h
*/
U8 SGLOffset2; /* 5Ah
*/
U8 SGLOffset3; /* 5Bh
*/
U32 Reserved3; /* 5Ch
*/
U32 Reserved4; /* 60h
*/
U32 SenseBufferLowAddr; /* 64h
*/
SGE_IO_UNION SGL; /* 68h
*/
} MSG_SCSI_IO32_REQUEST, MPI_POINTER PTR_MSG_SCSI_IO32_REQUEST,
SCSIIO32Request_t, MPI_POINTER pSCSIIO32Request_t;
next reply other threads:[~2007-02-27 1:10 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-27 1:10 Moore, Eric [this message]
2007-02-27 1:10 ` end to end error recovery musings Moore, Eric
2007-02-27 16:50 ` Martin K. Petersen
2007-02-27 16:50 ` Martin K. Petersen
2007-02-27 18:51 ` Ric Wheeler
2007-02-27 19:02 ` Alan
2007-02-27 19:02 ` Alan
2007-02-27 18:39 ` Andreas Dilger
2007-02-27 19:07 ` Martin K. Petersen
2007-02-27 19:07 ` Martin K. Petersen
2007-02-27 23:39 ` Alan
2007-02-27 23:39 ` Alan
2007-02-27 22:51 ` Martin K. Petersen
2007-02-27 22:51 ` Martin K. Petersen
2007-02-28 13:46 ` Douglas Gilbert
2007-02-28 17:16 ` Martin K. Petersen
2007-02-28 17:30 ` James Bottomley
2007-02-28 17:42 ` Martin K. Petersen
2007-02-28 17:52 ` James Bottomley
2007-03-01 1:28 ` H. Peter Anvin
2007-03-01 14:25 ` James Bottomley
2007-03-01 17:19 ` H. Peter Anvin
2007-02-28 15:19 ` Moore, Eric
2007-02-28 15:19 ` Moore, Eric
2007-02-28 17:27 ` Martin K. Petersen
-- strict thread matches above, loose matches on Subject: below --
2007-02-23 14:15 Ric Wheeler
2007-02-23 14:15 ` Ric Wheeler
2007-02-24 0:03 ` H. Peter Anvin
2007-02-24 0:37 ` Andreas Dilger
2007-02-24 2:05 ` H. Peter Anvin
2007-02-24 2:32 ` Theodore Tso
2007-02-24 18:39 ` Chris Wedgwood
2007-02-26 5:33 ` Neil Brown
2007-02-26 13:25 ` Theodore Tso
2007-02-26 15:15 ` Alan
2007-02-26 15:18 ` Ric Wheeler
2007-02-26 17:01 ` Alan
2007-02-26 16:42 ` Ric Wheeler
2007-02-26 15:17 ` James Bottomley
2007-02-26 18:59 ` H. Peter Anvin
2007-02-26 22:46 ` Jeff Garzik
2007-02-26 22:53 ` Ric Wheeler
2007-02-27 1:19 ` Alan
2007-02-26 6:01 ` Douglas Gilbert
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=664A4EBB07F29743873A87CF62C26D705D6DDB@NAMAIL4.ad.lsil.com \
--to=eric.moore@lsi.com \
--cc=Clark_Nathan@emc.com \
--cc=DeSmet_Jochen@emc.com \
--cc=Farmer_Matt@emc.com \
--cc=James.Bottomley@SteelEye.com \
--cc=Mizar_Sunita@emc.com \
--cc=Singh_Arvinder@emc.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=htejun@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mlord@pobox.com \
--cc=neilb@suse.de \
--cc=ric@emc.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.