AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<anurag.agarwal@lsi.com>,<dl-designreview@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	1132	4B6B9C4E.3070306@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 16 Feb 2010 13:58:53 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: Anurag Agarwal <anurag.agarwal@lsi.com>
Cc: DL-ONStor-Design Review <dl-designreview@lsi.com>
Subject: Re: Flexible Log Design Document for Review
Message-ID: <20100216135853.22473ec9@ripper.onstor.net>
In-Reply-To: <4B6B9C4E.3070306@lsi.com>
References: <5D3F3304755C724285AA5789BA159920BAD3959C@cosmail03.lsi.com>
 <2E3074EBA7791D4E8CDEEAA5DC8EFC27103232EB@cosmail03.lsi.com>
 <4B6B9C4E.3070306@lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 4 Feb 2010 21:19:26 -0700 Anurag Agarwal
<anurag.agarwal@lsi.com> wrote:

> Hi Jonathan,
> 
> Thanks for the comments. My replies are inline.
> 
> Goldick, Jonathan wrote:
> > 1. Fix the copyright to be 2010 LSI
> >   
> > 2. Table of Contents is empty
> > 3. Chapter 1, Can we get a hyperlink to a document that we add to
> > the ONStorNAS sharepoint site?  We really need to get all documents
> > placed in the appropriate directory.  If there are access problems
> > you can let me, BrianS, or the helpdesk know. 4. Chapter 3, the
> > default listed is after block 1026 but that is inconsistent with
> > the subsequent statement of being 1MB aligned.  This comment
> > appears twice. 
> I will update all these in the document.
> > 5. In 5.1, you cannot have the owner block move.  This has very bad
> > failure modes in a cluster during a change that could impact split
> > brain resolution. 6. In 5.3, how can the log possibly be extended
> > to the next MByte if the owner block immediately follows it?
> > Doesn't this ensure that there will never be available contiguous
> > space?  Again, we should not move the owner block. 
> This has been clarified by Jobi. Owner block is still in the file 
> system. Size of reserved blocks has been changed from 64M to 1M and
> it now just contains the owner block at the end of reserve area. File 
> system space starts at the end of reserved blocks. Now log is part of 
> file system space. Log can be  now any where in the file system not
> at a fixed location.
> > 7. In 5.4, how will you store the log lun with only these changes?
> > I imagine you could add the log lun to the start or end of the file
> > system and then use the associated block number but that should be
> > spelled out. 
> This feature is not adding a new lun to file system as log lun. It
> just allows placing of log on a lun which is already part of file
> system. That lun will not be exclusively used for log. Just the start
> block for log will be computed from that lun.


IMHO that needs to be part of this.  One of the major reasons for
adding this functionality is so that a customer can spend a lot of money
(with us) on some super-fast storage that is relatively small, used
for, say, just the log.  And other handling differences for that lun
might be desired as well.  Maybe that lun is officially part of the
volume, but we would then need a way to mark it as just for the log.
That pertains both to the UI and the underlying, of course.


> > 8. In 5.6, keeping the log segment count the same may not be
> > optimal.  We only truncate a segment at a time and that can be
> > pretty large now.  We could reduce the problems described in 5.7 if
> > the segment is not so large.  What is the advantage of keeping the
> > segments limited to 64? 
> This was discussed during the design. Increasing the segments would
> have required more bits in each inode. Increasing number of segment
> would have increased size of incore inode. So it was decided to keep
> the number of segments to constant to 64 and change the size of
> segment depending on the log size. Even with largest log of 1G, max
> segment size will be 16M.
> > 9. In 5.7, what are the best case and worst case number of disk
> > I/O(s) needed as a function of log size?  Same for memory.  Given a
> > 1-3ms avg read I/O time how long will replay take? 
> Number of disk I/O would depending of the size of active log. I have
> not worked out the worst case log replay time. I would assume that in
> the worst case size of active log could be 1G, and hence worst case
> disk I/O can be 16 times the current worst case. In fact, it will be
> 32 times, as now log needs to be read twice from the disk. In the
> current logic, complete log is read once and both the passes of log
> replay are done on in-core log. Now for both the passes log needs to
> be read from the disk.
> 
> As far as memory consumption is considered, now complete log is not 
> going to be kept in memory so memory pressure of log replay should
> not be very high. This was discussed at length.
> > 10. Will this change affect the number of parallel log replays we
> > allow?  Currently that is a function of log I/O(s) that will be
> > required. 
> This logic is yet to be worked out.
> > 11. In 5.13, this is not true if we allow the owner block to move
> > as this would affect split brain resolution.
> >
> >
> >   
> Owner block is still in the file system, only location of owner block
> is now read from the lun label. All the logic of owner block update
> still remains in the file system, so it should not affect split brain 
> resolution logic. There should not be any clustering related issues.
> 
> Regards,
> Anurag.
> >
> >
> > -----Original Message-----
> > From: Ariyamannil, Jobi 
> > Sent: Monday, February 01, 2010 1:22 PM
> > To: DL-ONStor-Design Review
> > Cc: Agarwal, Anurag
> > Subject: FW: Flexible Log Design Document for Review
> >
> >
> >
> > -----Original Message-----
> > From: Anurag Agarwal [mailto:anurag.agarwal@lsi.com] 
> > Sent: Thursday, January 28, 2010 6:14 PM
> > To: Ariyamannil, Jobi; Kozlovsky, Maxim
> > Subject: Flexible Log Design Document for Review
> >
> > Hi,
> >
> > Here is the design document for Flexible Log for review. Please
> > send me your review comments.
> >
> > I still have problem sending email to following address:
> >
> > <dl-onstor-design review@lsi.com>. It does not work from my
> > thunderbird email-client.
> >
> > Regards,
> > Anurag.
> > 