|To:||Dave Chinner <david@xxxxxxxxxxxxx>|
|Subject:||Re: xfs_repair deleting realtime files.|
|From:||Anand Tiwari <tiwarikanand@xxxxxxxxx>|
|Date:||Tue, 25 Sep 2012 19:26:32 -0600|
|Cc:||Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx|
|Dkim-signature:||v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zGua0sswgZxP/DZkPwVLeS0PfQGZe4LxMC6YkFMj61I=; b=AfO9+dsmhZFn9GlnlVyphLu3W3ksv6BlygIU7MUaL1/fP/1GML43CNeDDWzXJncR+F BBiLZw/qlGWNw2n7p6VCdGfVJcknGYWNxXkJtMA+3v+uCFR0YAkpEnCT4a7f0Wv9o2TI Uwln4nWaj6JFopNQlkV25ODa17TDChpaQUMMD5Rx17SdliBy9OD/d541lQ/V3IQ7W6NK 4aEq0nAbarnWQoBs/P13pOLwEnx1Bjv4sNDFCzZ3t8QbAQoEwPcg8daNH9tJenGLsOoH adBrRcw+pMeMOd6SEYFb89ugnBdbGEk00vzdFJpIgFLRDqQ8V3XHAm46PkTyYXes9IXG KIkw==|
|References:||<CAHt31_9K_vrzoqwSVsz-6VNVmMUzMyGCFEZfviRV-xPcUqv8-w@xxxxxxxxxxxxxx> <505BF45D.5050909@xxxxxxxxxxx> <20120924075551.GF20960@dastard> <CAHt31_8rEc93vpnbbKngY4uS0kAct3Z5A+2G0LmBzv5rWKdSfA@xxxxxxxxxxxxxx>|
On Mon, Sep 24, 2012 at 6:51 AM, Anand Tiwari <tiwarikanand@xxxxxxxxx> wrote:
I think this is what happening. If we have following conditions,
1) we have more than 8gb contiguous space available to allocate. ( i.e. more than 2^21 4k blocks)
2) only one file is open for writing in real-time volume.
To satisfy first condition, I just took empty file-system.
Now lets start allocating, lets say in chucks of 25000, realtime allocator will have no problem allocating "exact" block while searching forward.
xfs_rtfind_forw(). It will allocate 49 "real-time extents", where the 49th "real-time extent" is partially full. (25000/512 = 48)
everything is fine for first 83 allocations, as we were able to grow the extent. Now we have 2075000 (25000*83) blocks in first extent ie 4053 "real-time extents" (where last "real-time extent" is partially full).
for 84th allocation, real-time allocator will allocate another 49 "real-time extents" as it does not know about maximum extent size, but we can not grow the extent in xfs_bmap_add_extent_unwritten_real(). so we insert a new extent (case BMAP_LEFT_FILLING). now the new extent starts from 2075000, which is not aligned with rextsize (512 in this case).
To fix this, I see two options,
1) fix real-time allocator and teach it about maximum extent size.
2) for real-time files, aligned new extent before inserting.
In my opinion, we should not worry about either of above, as this looks good method for allocation. I can fix xfs_repair tool and make it aware of these conditions ("real-time extents" shared by two or more extents).
Let me know what you guys think,
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 0/3] xfs: allocation worker causes freelist buffer lock hang, Dave Chinner|
|Next by Date:||Re: xfs_repair deleting realtime files., Dave Chinner|
|Previous by Thread:||Re: xfs_repair deleting realtime files., Anand Tiwari|
|Next by Thread:||Re: xfs_repair deleting realtime files., Dave Chinner|
|Indexes:||[Date] [Thread] [Top] [All Lists]|