Skip to content

Commit 9b72a0f

Browse files
committed
Fix fallocate issue
1 parent f471d42 commit 9b72a0f

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
@@ -6601,6 +6601,13 @@ RETT_FSTAT64 _nvp_FSTAT64(INTF_FSTAT64)
66016601
return result;
66026602
}
66036603
*/
6604+
6605+
/* Before doing an fallocate we do an fsync
6606+
*
6607+
* We do an fsync (relink) because we want be consistent with how the kernel and SplitFS sees the file.
6608+
*
6609+
* TODO: Figure out if ext4 implementation will re-allocate the existing blocks (for e.g to make it contiguous)
6610+
*/
66046611
RETT_POSIX_FALLOCATE _nvp_POSIX_FALLOCATE(INTF_POSIX_FALLOCATE)
66056612
{
66066613
CHECK_RESOLVE_FILEOPS(_nvp_);
@@ -6626,13 +6633,6 @@ RETT_POSIX_FALLOCATE _nvp_POSIX_FALLOCATE(INTF_POSIX_FALLOCATE)
66266633
_nvp_FSYNC(file);
66276634
NVP_LOCK_NODE_WR(nvf);
66286635

6629-
// Doing because our mmaps maybe stale after fallocate
6630-
clear_tbl_mmap_entry(tbl_app, NUM_APP_TBL_MMAP_ENTRIES);
6631-
6632-
#if DATA_JOURNALING_ENABLED
6633-
clear_tbl_mmap_entry(tbl_over, NUM_OVER_TBL_MMAP_ENTRIES);
6634-
#endif
6635-
66366636
result = _nvp_fileops->POSIX_FALLOCATE(CALL_POSIX_FALLOCATE);
66376637

66386638
int ret = fstat(file, &sbuf);
@@ -6644,6 +6644,12 @@ RETT_POSIX_FALLOCATE _nvp_POSIX_FALLOCATE(INTF_POSIX_FALLOCATE)
66446644
return result;
66456645
}
66466646

6647+
/* Before doing an fallocate we do an fsync
6648+
*
6649+
* We do an fsync (relink) because we want be consistent with how the kernel and SplitFS sees the file.
6650+
*
6651+
* TODO: Figure out if ext4 implementation will re-allocate the existing blocks (for e.g to make it contiguous)
6652+
*/
66476653
RETT_POSIX_FALLOCATE64 _nvp_POSIX_FALLOCATE64(INTF_POSIX_FALLOCATE64)
66486654
{
66496655
CHECK_RESOLVE_FILEOPS(_nvp_);
@@ -6669,13 +6675,6 @@ RETT_POSIX_FALLOCATE64 _nvp_POSIX_FALLOCATE64(INTF_POSIX_FALLOCATE64)
66696675
_nvp_FSYNC(file);
66706676
NVP_LOCK_NODE_WR(nvf);
66716677

6672-
// Doing because our mmaps maybe stale after fallocate
6673-
clear_tbl_mmap_entry(tbl_app, NUM_APP_TBL_MMAP_ENTRIES);
6674-
6675-
#if DATA_JOURNALING_ENABLED
6676-
clear_tbl_mmap_entry(tbl_over, NUM_OVER_TBL_MMAP_ENTRIES);
6677-
#endif
6678-
66796678
result = _nvp_fileops->POSIX_FALLOCATE64(CALL_POSIX_FALLOCATE64);
66806679

66816680
int ret = fstat(file, &sbuf);
@@ -6687,12 +6686,11 @@ RETT_POSIX_FALLOCATE64 _nvp_POSIX_FALLOCATE64(INTF_POSIX_FALLOCATE64)
66876686
return result;
66886687
}
66896688

6690-
/* Before doing an fallocate we do an fsync and then clear the memory map table.
6689+
/* Before doing an fallocate we do an fsync
66916690
*
66926691
* We do an fsync (relink) because we want be consistent with how the kernel and SplitFS sees the file.
66936692
*
6694-
* We clear the memory map table because when fallocate system call is made, it might move the existing pieces
6695-
* to a different block, thus making the data mmapped stale.
6693+
* TODO: Figure out if ext4 implementation will re-allocate the existing blocks (for e.g to make it contiguous)
66966694
*/
66976695
RETT_FALLOCATE _nvp_FALLOCATE(INTF_FALLOCATE)
66986696
{
@@ -6719,13 +6717,6 @@ RETT_FALLOCATE _nvp_FALLOCATE(INTF_FALLOCATE)
67196717
_nvp_FSYNC(file);
67206718
NVP_LOCK_NODE_WR(nvf);
67216719

6722-
// Doing because our mmaps maybe stale after fallocate
6723-
clear_tbl_mmap_entry(tbl_app, NUM_APP_TBL_MMAP_ENTRIES);
6724-
6725-
#if DATA_JOURNALING_ENABLED
6726-
clear_tbl_mmap_entry(tbl_over, NUM_OVER_TBL_MMAP_ENTRIES);
6727-
#endif
6728-
67296720
result = _nvp_fileops->FALLOCATE(CALL_FALLOCATE);
67306721

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

0 commit comments

Comments
 (0)