lkml.org 
[lkml]   [2022]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RESEND PATCH 0/4] Implement File-Based optimization functionality
On Fri, Nov 4, 2022 at 9:37 PM Matias Bjørling <m@bjorling.me> wrote:
>
> On 03/11/2022 07.11, Juhyung Park wrote:
> ...
> >
> > Is the idea really an utter madness? Majority of regular files that may
> > be of interest from the perspective of UFS aren't reflinked or
> > snapshotted (let alone the lack of support from ext4 or f2fs).
> >
> > Device-side fragmentation is a real issue [1] and it makes more than
> > enough sense to defrag LBAs of interests to improve performance. This
> > was long overdue, unless the block interface itself changes somehow.
>
> There are ongoing work with UFS to extend the block interface with
> zones. This approach eliminates the mismatch between the device-side
> mapping and host-side mapping and lets the host and device collaborate
> on the data placement.
>
> >
> > The question is how to implement it correctly without creating a mess
> > with mismatched/outdated LBAs as you've mentioned, preferably through
> > file-system's integration: If the LBAs in questions are indeed
> > reflinked, how do we handle it?, If the LBAs are moved/invalidated from
> > defrag or GC, how do we make sure that UFS is up-to-date?, etc.
>
> If using zoned UFS, the file-system can use zones for LBA tracking,
> eliminating the mismatched/outdated LBA issue. f2fs already supports
> this approach (works today with SMR HDDs and ZNS SSDs). It'll extend to
> UFS when zone support is added/implemented.
>

More reasons to have this functionality integrated with the
file-system instead of allowing users to specify random LBA ranges.

\
 
 \ /
  Last update: 2022-11-05 06:24    [W:0.026 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site