On Wed, Jan 14, 2009 at 11:13 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > this brings in a new dimension of analysis: > > On Wed, Jan 14, 2009 at 1:14 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >> >> Correct.... but that also raises few more questions. Sandeep , do you >> have any pre-requisites about the sizing of disks for OHSM to work ?? >> For example lets say I have 3 disks d1, d2 & d3 in descending order of >> speed. Do all of them have to be of same size ? If they are then you >> really don't need to worry much about space preallocation, because you > > i am confused....why "preallocation" in the first place? if the To reduce fragmentation. This is for a file being written, just like you have opened a file in vim and you just writing blocks after blocks. > destination is guaranteed to have only the current kernel thread > writing to it, then don't have to preallocate. and if destination is > writable by many processes, then u need the source to be in readonly > mode, to justify the preallocation. > Are you talking about ohsm's source and destination context ? Looks like. If so, then we don't have to do anything with preallocation. Its just an optimization used by ext2/3 to allocate blocks sequentially. The FS will do that for me. See, we allocate the same number of blocks as of the source inode. The source inode can have 1000 blocks, So, when you try to allocate new inodes for backing up, when you allocate the first block, then it will preallocate some 8 blocks for you. So, that further allocation would be linear and you will reduce the chances of fragmentation. It has nothing to do with which thread is writing. See, > if source is NOT in readonly mode, then pointless to preallocate, as > source files may grow bigger or smaller while backing up operation is > going. > We mentioned that even if the source is in read/write mode, we just take a lock on the source inode for some small period of time. And all i/o's are queued. SO, eventually the source becomes read only. > and for the same reason, it is also impossible to compare disk size > between d1 and d2 to determine storage space sufficiency. > We avoided the previous problem, this also vanishes away. We can easily calculate the value for this and compare. > (ext2's terminology of "preallocation" is not the same as yours, as it > is "preallocated" but not allocated until when needed, so space is > still available for allocation by anyone). > We mentioned earlier as well, that we dont change the default behavior of the ext2. Every behavior remains intact except for the ghosting the size of the FS. What you are saying is a default behavior and can happen otherwise too. Does that answer your question ? >> know that if you had space in d1 to allocate an inode in first place, >> you can replicate the same layout in d2. >> >> Problem comes when d2 is less than d1. Is it possible that you migrate >> only some of the blocks to d2 and leave some in d1 if d2 runs out of >> space ? >> > > > -- > Regards, > Peter Teoh > -- Regards, Sandeep. "To learn is to change. Education is a process that changes the learner." -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
