mbox series

[RESEND,0/4] Implement File-Based optimization functionality

Message ID 20221102053058.21021-1-lijiaming3@xiaomi.corp-partner.google.com
Headers show
Series Implement File-Based optimization functionality | expand

Message

Jiaming Li Nov. 2, 2022, 5:30 a.m. UTC
From: lijiaming3 <lijiaming3@xiaomi.com>

Stoage devices have a long lifespan. Device performance over its
lifespan is not constant and may deteriorate over time. To remedy
this, JEDEC came up with the UFS File-Based-Optimization (FBO)
extension (JC-64.1-22-67). The FBO feature improves this performance
regression via physical defragmentation of the LBA ranges that are
associated with specific files.

This feature expects the following host-device dialog:
1) The host let the device know of lba range(s) of interest. Those
   ranges are typically associated with a specific file. One can
   obtain it from the iNode of the file and some offset calculations.
2) The host ask the device for the current physical fragmentation
   level of this file.
3) Should it requires, the host instruct the device to perform
   defragmentation.
4) Upon successful termination of the defragmentation phase, the host
   may ask for the new fragmentation level of the file.

lijiaming3 (4):
  scsi:ufs:remove sanity check
  scsi:ufs:add File-Based Optimization descriptor
  scsi:ufs:add FBO module
  scsi:ufs:add fbo functionality

 Documentation/ABI/testing/sysfs-driver-ufs | 129 +++++
 drivers/ufs/core/Kconfig                   |  12 +
 drivers/ufs/core/Makefile                  |   1 +
 drivers/ufs/core/ufs-sysfs.c               |  26 ++
 drivers/ufs/core/ufsfbo.c                  | 519 +++++++++++++++++++++
 drivers/ufs/core/ufsfbo.h                  |  23 +
 drivers/ufs/core/ufshcd.c                  |  15 +-
 include/ufs/ufs.h                          |  16 +
 include/ufs/ufshcd.h                       |   1 +
 9 files changed, 734 insertions(+), 8 deletions(-)
 create mode 100644 drivers/ufs/core/ufsfbo.c
 create mode 100644 drivers/ufs/core/ufsfbo.h

Comments

Christoph Hellwig Nov. 9, 2022, 12:31 p.m. UTC | #1
On Thu, Nov 03, 2022 at 03:11:16PM +0900, Juhyung Park wrote:
> Is the idea really an utter madness?

Yes.

> 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).

Linux does not require you in any way to use obsolete file systems
desings only on any given block device.

> 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.

Or maybe random writes to flash aren't a good idea if you FTL sucks?
Full blown FTLs tend to not do any extent based mappings, so
fragmentation does not matter.  The price paid for that is much larger
FTL tables.  If you stop pretending flash is random writable through
saner interfaces like ZNS you automatically solve this fragmentation
problem as well.

> 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.

The fix is to plug the leaking abtractions in UFS.  If it wants to look
like a random writable block device it better perform when doing that.
And if it doesn't want to pay the prize for that it'd better expose
an abstraction that actually fits the underlying media.  It's not like
some of us haven't worked on that for the last decade.