During delayed allocation extent conversion or unwritten extent conversion, we need to reserve some blocks for transactions reservations. We need to reserve these blocks in case a btree split occurs
As previously discussed, the idea sounds reasonable to me. I'll look at the patch shortly. --Tim --On 4 June 2007 2:52:19 PM +1000 David Chinner <dgc@xxxxxxx> wrote: During delayed allocation extent
Hi Dave, As an aside, I don't understand the following bit of code in xfs_reserve_blocks(): /* * If our previous reservation was larger than the current value, * then move any unused blocks back to t
Because mp->m_resblks_avail is the amount of reservation space we have *unallocated*. i.e. 0 <= mp->m_resblks_avail <= mp->m_resblks IOWs, when we have used some blocks and then change mp->m_resblks,
Hi Dave, Putting the xfs_reserve_blocks discussion to the side.... (discussed separately) Back to the review, looking at the changes: --On 4 June 2007 2:52:19 PM +1000 David Chinner <dgc@xxxxxxx> wro
*nod* BTW, did you try that patch I sent? Yes, and so now you can grow a completely full filesystem :) It's a SWAG. I think it's sufficient to begin with. If it proves to be a problem, then we can ch
It would be more correct of XFS to start doing the right thing by reporting different values for b_free and b_avail in statfs(2) - this code in xfs_mount.c::xfs_statvfs() ... statp->f_bfree = statp->
During delayed allocation extent conversion or unwritten extent conversion, we need to reserve some blocks for transactions reservations. We need to reserve these blocks in case a btree split occurs
As previously discussed, the idea sounds reasonable to me. I'll look at the patch shortly. --Tim --On 4 June 2007 2:52:19 PM +1000 David Chinner <dgc@xxxxxxx> wrote: During delayed allocation extent
Hi Dave, As an aside, I don't understand the following bit of code in xfs_reserve_blocks(): /* * If our previous reservation was larger than the current value, * then move any unused blocks back to t
Because mp->m_resblks_avail is the amount of reservation space we have *unallocated*. i.e. 0 <= mp->m_resblks_avail <= mp->m_resblks IOWs, when we have used some blocks and then change mp->m_resblks,
Hi Dave, Putting the xfs_reserve_blocks discussion to the side.... (discussed separately) Back to the review, looking at the changes: --On 4 June 2007 2:52:19 PM +1000 David Chinner <dgc@xxxxxxx> wro
*nod* BTW, did you try that patch I sent? Yes, and so now you can grow a completely full filesystem :) It's a SWAG. I think it's sufficient to begin with. If it proves to be a problem, then we can ch
It would be more correct of XFS to start doing the right thing by reporting different values for b_free and b_avail in statfs(2) - this code in xfs_mount.c::xfs_statvfs() ... statp->f_bfree = statp->