On Wed, Jul 18, 2018 at 3:48 PM cgxu519 <cgxu519@xxxxxxx> wrote: > > On 07/18/2018 03:38 PM, Yan, Zheng wrote: > > On Wed, Jul 18, 2018 at 11:29 AM cgxu519 <cgxu519@xxxxxxx> wrote: > >> On 07/13/2018 03:12 AM, Patrick Donnelly wrote: > >>> On Thu, Jul 12, 2018 at 8:13 AM, John Spray <jspray@xxxxxxxxxx> wrote: > >>>> On Thu, Jul 12, 2018 at 2:57 PM cgxu519 <cgxu519@xxxxxxx> wrote: > >>>>> On 07/12/2018 05:37 PM, John Spray wrote: > >>>>>> On Thu, Jul 12, 2018 at 7:38 AM Chengguang Xu <cgxu519@xxxxxxx> wrote: > >>>>>>> Hi guys, > >>>>>>> > >>>>>>> Currently, we can arbitrarily change max file size in cephfs if the size is just larger than 65536. > >>>>>>> Could we change it to only allowing increment? It seems there is no good reason to decrease the size. > >>>>>>> What do you think? > >>>>>> If we made increases irreversible, then it would be a bit "scary" for > >>>>>> people to modify the setting at all -- it feels more user friendly to > >>>>>> let people change it both ways so that they can correct their mistake > >>>>>> if they set it too high. > >>>>>> > >>>>>> While it's a bit annoying that someone can set a max_file_size that is > >>>>>> really smaller than their largest file, I think it's still useful to > >>>>>> be able to limit the size of new files. We just need to make sure > >>>>>> it's clear to users that this is the maximum size for new files rather > >>>>>> than the actual largest file that exists. > >>>>> One thing that I concern is when max_file_size is smaller than some existing > >>>>> files then we probably cannot operate(read/write) exceeded data range. > >>>>> Because sanity check will adjust real read/write size or even return > >>>>> error directly > >>>>> when offset larger than max_file_size. So it looks like a kind of > >>>>> truncation and > >>>>> maybe in some cases applications think the file is incomplete. > >>>> I haven't looked in detail, but hopefully we could fix that so that > >>>> the max_filesize() check is only enforced when exceeding the current > >>>> size of the file. I agree that blocking overwrites in an existing big > >>>> file is a weird behaviour. > >>> Agreed, issue here: http://tracker.ceph.com/issues/24894 > >> Hello, > >> > >> I've did some attempts to fix the issue in kernel client side, > >> however, considering both 32/64bit clients could be exist for same cephfs, > >> it seems taking bigger value between current file size and sb->s_maxbytes > >> is not always correct. Also some operations(e.g. buffered read) go into > >> generic VFS code, so adjusting validation condition there may impact others. > >> (I think local filesystems will be OK but not so sure about other > >> distributed filesystems) > >> > >> IMO, maybe it's better to fix the issue in cephfs not kernel client. I > >> think at least > >> we should not allow changing max_file_size to smaller than current maximum > >> file size. At the same time, I think max_file_size should maintain in > >> filesystem level > >> not in MDSMap which is impacting all filesystems in cluster. > >> > >> Please let me know if I'm missing something. > >> > > how about always set sb->s_maxbytes to MAX_LFS_FILESIZE. do the check > > in cephfs code. > > Is it OK for buffered write? Buffered write is through ceph_write_iter(). we can do the check after calling generic_write_checks() > > Thanks, > Chengguang > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
