* Re: [lustre-devel] Rationale behind pre-create objects
[not found] <CABnqofwzxyZW5DGGn5sXS-=KG6K40MJVTUBrbA6CVOR=K1eT=Q@mail.gmail.com>
@ 2021-02-17 9:00 ` Andreas Dilger
0 siblings, 0 replies; only message in thread
From: Andreas Dilger @ 2021-02-17 9:00 UTC (permalink / raw)
To: Sudheendra Sampath; +Cc: lustre-devel
Yes, precreating OST objects avoids latency, but it is as much for network latency as it is for disk latency. For ldiskfs the inode allocation is in memory and journaled, so does not depend on seek latency at all.
Another reason to precreate objects is to ensure that the OST does not run out of inodes for files that the MDS already created. For ldiskfs this is an issue because the number of OST inodes is fixed at format time. For ZFS it is an issue because regular file IO can consume all the space and prevent inode allocation.
Finally, object precreation simplifies recovery because we have a good idea whether/which objects should exist or not after a server restart.
Cheers, Andreas
> On Feb 16, 2021, at 14:36, Sudheendra Sampath <sudheendra.sampath@gmail.com> wrote:
>
>
> Hi,
>
> I am curious to find the reason behind 'pre-create object' for a new file/directory creation.
>
> My wild guess is that when you are using 'spinning disks' as the backend storage, pre-creating objects before the actual data comes will minimize latency overhead of disk seek.
>
> If my wild guess is correct, my follow-up question is:
>
> If I am using SSD based devices as backend storage, do we need this pre-create anymore given that SSD are super-fast compared to spinning media ?
>
> Appreciate if anyone can provide some insight into this.
>
> Thanks,
>
> --
> Regards
>
> Sudheendra Sampath
> _______________________________________________
> lustre-devel mailing list
> lustre-devel@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
_______________________________________________
lustre-devel mailing list
lustre-devel@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
^ permalink raw reply [flat|nested] only message in thread