runlist_element * ntfs_cluster_alloc (ntfs_volume * vol, const VCN start_vcn, const s64 count, const LCN start_lcn, const NTFS_CLUSTER_ALLOCATION_ZONES zone);
Allocate count clusters preferably starting at cluster start_lcn or at the current allocator position if start_lcn is -1, on the mounted ntfs volume vol. zone is either DATA_ZONE for allocation of normal clusters or MFT_ZONE for allocation of clusters for the master file table, i.e. the $MFT/$DATA attribute.
start_vcn specifies the vcn of the first allocated cluster. This makes merging the resulting runlist with the old runlist easier.
You need to check the return value with IS_ERR. If this is false, the function was successful and the return value is a runlist describing the allocated cluster(s). If IS_ERR is true, the function failed and PTR_ERR gives you the error code.
Notes on the allocation algorithm =================================
There are two data zones. First is the area between the end of the mft zone and the end of the volume, and second is the area between the start of the volume and the start of the mft zone. On unmodified/standard NTFS 1.x volumes, the second data zone does not exist due to the mft zone being expanded to cover the start of the volume in order to reserve space for the mft bitmap attribute.
This is not the prettiest function but the complexity stems from the need of implementing the mft vs data zoned approach and from the fact that we have access to the lcn bitmap in portions of up to 8192 bytes at a time, so we need to cope with crossing over boundaries of two buffers. Further, the fact that the allocator allows for caller supplied hints as to the location of where allocation should begin and the fact that the allocator keeps track of where in the data zones the next natural allocation should occur, contribute to the complexity of the function. But it should all be worthwhile, because this allocator should: 1) be a full implementation of the MFT zone approach used by Windows NT, 2) cause reduction in fragmentation, and 3) be speedy in allocations (the code is not optimized for speed, but the algorithm is, so further speed improvements are probably possible).
We should be monitoring cluster allocation and increment the MFT zone size dynamically but this is something for the future. We will just cause heavier fragmentation by not doing it and I am not even sure Windows would grow the MFT zone dynamically, so it might even be correct not to do this. The overhead in doing dynamic MFT zone expansion would be very large and unlikely worth the effort. (AIA)
I have added in double the required zone position pointer wrap around logic which can be optimized to having only one of the two logic sets. However, having the double logic will work fine, but if we have only one of the sets and we get it wrong somewhere, then we get into trouble, so removing the duplicate logic requires _very_ careful consideration of _all_ possible code paths. So at least for now, I am leaving the double logic - better safe than sorry... (AIA)
- The volume lcn bitmap must be unlocked on entry and is unlocked on return. - This function takes the volume lcn bitmap lock for writing and modifies the bitmap contents.