On Tue, Sep 10, 2024 at 5:36 PM Ilya Dryomov <idryomov@xxxxxxxxx> wrote: > > On Tue, Sep 10, 2024 at 1:23 PM Milind Changire <mchangir@xxxxxxxxxx> wrote: > > > > Problem: > > CephFS fallocate implementation does not actually reserve data blocks > > when mode is 0. > > It only truncates the file to the given size by setting the file size > > in the inode. > > So, there is no guarantee that writes to the file will succeed > > > > Solution: > > Since an immediate remediation of this problem is not possible, I > > request users to vote on the most suitable approach to avoid breaking > > dependent software: > > 1. report EOPNOTSUPP (operation not supported) when mode is 0 > > 2. continue with existing implementation of file size truncation when mode is 0 > > Hi Milind, > > The kernel client went with (1) in 2018: > > https://github.com/ceph/ceph-client/commit/bddff633ab7bc60a18a86ac8b322695b6f8594d0 > > And according to Patrick the intent was to do the same for ceph-fuse > (libcephfs) as well: > > https://tracker.ceph.com/issues/36317#note-3 > > Did that part fall through the cracks? > > Thanks, > > Ilya > Thanks Ilya for the pointers. This has just recently landed on my plate. Also, I hadn't dug into the kernel and fuse client history. Looks like Patrick's suggestion was indeed implemented for only supporting punching holes. But the other modes weren't guarded against. Although we do have tests for FALLOC_FL_KEEP_SIZE and FALLOC_FL_PUNCH_HOLE, there's no guard to test for the default action when mode is 0. The default action is to truncate the file to the given size. So, it does look like things did fall through the cracks. I haven't peeked into the kernel sources yet. -- Milind _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |