You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we're allocating tfs extents more often than we need to. Explore the possibility of extending an existing file extent on append rather than allocating a new one. To accommodate the extension, a larger default storage allocation size could be used for each new extent, or id_heap_set_area could be used to try and extend an existing allocation (failure would just mean creating a new extent).
We could also look at merging extents that are contiguous on disk, but such conditions should become much less frequent if the above is implemented, so it's not clear how valuable such a function would be.
Once we complete the removal of all temporary buffers for retaining extent data, we can also remove the 1MB maximum extent size.
The text was updated successfully, but these errors were encountered:
Extension of extents to fill allocated space was merged with #1207. We can still choose to:
attempt to tack on to an existing extent allocation (double?) by using id_heap_set_area to try and reserve the space
If this fails, revert to creating a new extent.
join extents that are adjacent on storage (keeps the amount of file metadata down)
remove (or raise) the extent size maximum
This was required a long time ago when we needed to allocate contiguous memory to hold an entire extent, which is no longer the case. (Note: Given that id heap allocations are aligned (but not padded) to size, this may result in greater use of storage space, which in cases like the boot partition would just be wasted space. There are some applications within the kernel that currently rely on this property of the id heap, and it does allow for a faster bitmap search, but we could explore a revisitation or parameterizing behavior on heap creation.)
Right now we're allocating tfs extents more often than we need to.
Explore the possibility of extending an existing file extent on append rather than allocating a new one.To accommodate the extension, a larger default storage allocation size could be used for each new extent, or id_heap_set_area could be used to try and extend an existing allocation (failure would just mean creating a new extent).We could also look at merging extents that are contiguous on disk, but such conditions should become much less frequent if the above is implemented, so it's not clear how valuable such a function would be.
Once we complete the removal of all temporary buffers for retaining extent data, we can also remove the 1MB maximum extent size.
The text was updated successfully, but these errors were encountered: