Skip to content

Commit 2c0f930

Browse files
committed
Fix fallocate issue
1 parent 96dc8bb commit 2c0f930

File tree

2 files changed

+16
-25
lines changed

2 files changed

+16
-25
lines changed

implementation.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ Some of the implementation details of intercepted calls in SplitFS
33
- `fallocate, posix_fallocate`
44
- We pass this to the kernel.
55
- But before we pass this on to the kernel we fsync (relink) the file so that the kernel and SplitFS both see the file contents and metadata consistently.
6-
- We also clear the mmap table in SplitFS because they might get stale after the system call.
76
- We update the file size after the system call accordingly in SplitFS before returning to the application.
7+
- TODO: Figure out if ext4 implementation of fallocate will move the existing blocks to a new location (maybe to make it contiguous?). If yes, we will also have clear the mmap table in SplitFS because they might get stale after the system call.
88
- `sync_file_range`
99
- sync_file_range guarantees data durability only for overwrites on certain filesystems. It does not guarantee metadata durability on any filesystem.
1010
- In case of POSIX mode of SplitFS too, we guarantee data durability and not metadata durability, i.e we want to provide the same guarantees as posix.

splitfs/fileops_nvp.c

Lines changed: 15 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -6736,6 +6736,13 @@ RETT_FSTAT64 _nvp_FSTAT64(INTF_FSTAT64)
67366736
return result;
67376737
}
67386738
*/
6739+
6740+
/* Before doing an fallocate we do an fsync
6741+
*
6742+
* We do an fsync (relink) because we want be consistent with how the kernel and SplitFS sees the file.
6743+
*
6744+
* TODO: Figure out if ext4 implementation will re-allocate the existing blocks (for e.g to make it contiguous)
6745+
*/
67396746
RETT_POSIX_FALLOCATE _nvp_POSIX_FALLOCATE(INTF_POSIX_FALLOCATE)
67406747
{
67416748
CHECK_RESOLVE_FILEOPS(_nvp_);
@@ -6761,13 +6768,6 @@ RETT_POSIX_FALLOCATE _nvp_POSIX_FALLOCATE(INTF_POSIX_FALLOCATE)
67616768
_nvp_FSYNC(file);
67626769
NVP_LOCK_NODE_WR(nvf);
67636770

6764-
// Doing because our mmaps maybe stale after fallocate
6765-
clear_tbl_mmap_entry(tbl_app, NUM_APP_TBL_MMAP_ENTRIES);
6766-
6767-
#if DATA_JOURNALING_ENABLED
6768-
clear_tbl_mmap_entry(tbl_over, NUM_OVER_TBL_MMAP_ENTRIES);
6769-
#endif
6770-
67716771
result = _nvp_fileops->POSIX_FALLOCATE(CALL_POSIX_FALLOCATE);
67726772

67736773
int ret = fstat(file, &sbuf);
@@ -6779,6 +6779,12 @@ RETT_POSIX_FALLOCATE _nvp_POSIX_FALLOCATE(INTF_POSIX_FALLOCATE)
67796779
return result;
67806780
}
67816781

6782+
/* Before doing an fallocate we do an fsync
6783+
*
6784+
* We do an fsync (relink) because we want be consistent with how the kernel and SplitFS sees the file.
6785+
*
6786+
* TODO: Figure out if ext4 implementation will re-allocate the existing blocks (for e.g to make it contiguous)
6787+
*/
67826788
RETT_POSIX_FALLOCATE64 _nvp_POSIX_FALLOCATE64(INTF_POSIX_FALLOCATE64)
67836789
{
67846790
CHECK_RESOLVE_FILEOPS(_nvp_);
@@ -6804,13 +6810,6 @@ RETT_POSIX_FALLOCATE64 _nvp_POSIX_FALLOCATE64(INTF_POSIX_FALLOCATE64)
68046810
_nvp_FSYNC(file);
68056811
NVP_LOCK_NODE_WR(nvf);
68066812

6807-
// Doing because our mmaps maybe stale after fallocate
6808-
clear_tbl_mmap_entry(tbl_app, NUM_APP_TBL_MMAP_ENTRIES);
6809-
6810-
#if DATA_JOURNALING_ENABLED
6811-
clear_tbl_mmap_entry(tbl_over, NUM_OVER_TBL_MMAP_ENTRIES);
6812-
#endif
6813-
68146813
result = _nvp_fileops->POSIX_FALLOCATE64(CALL_POSIX_FALLOCATE64);
68156814

68166815
int ret = fstat(file, &sbuf);
@@ -6822,12 +6821,11 @@ RETT_POSIX_FALLOCATE64 _nvp_POSIX_FALLOCATE64(INTF_POSIX_FALLOCATE64)
68226821
return result;
68236822
}
68246823

6825-
/* Before doing an fallocate we do an fsync and then clear the memory map table.
6824+
/* Before doing an fallocate we do an fsync
68266825
*
68276826
* We do an fsync (relink) because we want be consistent with how the kernel and SplitFS sees the file.
68286827
*
6829-
* We clear the memory map table because when fallocate system call is made, it might move the existing pieces
6830-
* to a different block, thus making the data mmapped stale.
6828+
* TODO: Figure out if ext4 implementation will re-allocate the existing blocks (for e.g to make it contiguous)
68316829
*/
68326830
RETT_FALLOCATE _nvp_FALLOCATE(INTF_FALLOCATE)
68336831
{
@@ -6854,13 +6852,6 @@ RETT_FALLOCATE _nvp_FALLOCATE(INTF_FALLOCATE)
68546852
_nvp_FSYNC(file);
68556853
NVP_LOCK_NODE_WR(nvf);
68566854

6857-
// Doing because our mmaps maybe stale after fallocate
6858-
clear_tbl_mmap_entry(tbl_app, NUM_APP_TBL_MMAP_ENTRIES);
6859-
6860-
#if DATA_JOURNALING_ENABLED
6861-
clear_tbl_mmap_entry(tbl_over, NUM_OVER_TBL_MMAP_ENTRIES);
6862-
#endif
6863-
68646855
result = _nvp_fileops->FALLOCATE(CALL_FALLOCATE);
68656856

68666857
int ret = fstat(file, &sbuf);

0 commit comments

Comments
 (0)