From: Juhyung Park <qkrwngud825@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jiaming Li <lijiaming3@xiaomi.corp-partner.google.com>,
alim.akhtar@samsung.com, avri.altman@wdc.com, bvanassche@acm.org,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
lijiaming3 <lijiaming3@xiaomi.com>
Subject: Re: [RESEND PATCH 0/4] Implement File-Based optimization functionality
Date: Thu, 3 Nov 2022 15:11:16 +0900 [thread overview]
Message-ID: <c5948336-19fc-ddd3-bc34-aba2d1b02302@gmail.com> (raw)
In-Reply-To: <Y2IuhG8nBJj0F1fd@infradead.org>
On 11/2/22 17:47, Christoph Hellwig wrote:
> On Wed, Nov 02, 2022 at 01:30:54PM +0800, Jiaming Li wrote:
>> 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.
>
> This is completely and utter madness. Files are a logic concept, that
> is non-unique (reflinks, snapshot) and can change at any time
> (defragmentation, GC, dedup). Whoever came up with this scheme is on
> crack and the it has no business being in the Linux kernel
>
> NAK.
>
>
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.
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.
>
> From: lijiaming3 <lijiaming3@xiaomi.com>
>
> add fbo analysis and defrag function
>
> We can send LBA info to the device as a comma separated string. Each
> adjacent pair represents a range:<open-lba>,<close-lba>.
> e.g. The LBA range of the file is 0x1234,0x3456;0x4567,0x5678
> echo 0x1234,0x3456,0x4567,0x5678 > fbo_send_lba
>
Like, ew. Why would we ever want *the userspace* to be able to
manipulate this directly?
[1]
https://www.usenix.org/conference/atc17/technical-sessions/presentation/hahn
- Section 3.3: "For example, even if a file was not fragmented at all in
the logical space (DoFL=1), if the file had a DoFP value of 0.5, the I/O
throughput became only 48% of that with DoFP=0."
next prev parent reply other threads:[~2022-11-03 6:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 5:30 [RESEND PATCH 0/4] Implement File-Based optimization functionality Jiaming Li
2022-11-02 5:30 ` [RESEND PATCH 1/4] scsi:ufs:remove sanity check Jiaming Li
2022-11-02 7:23 ` Avri Altman
2022-11-02 5:30 ` [RESEND PATCH 2/4] scsi:ufs:add File-Based Optimization descriptor Jiaming Li
2022-11-02 7:46 ` Avri Altman
2022-11-02 5:30 ` [RESEND PATCH 3/4] scsi:ufs:add FBO module Jiaming Li
2022-11-02 8:11 ` Avri Altman
2022-11-14 21:21 ` kernel test robot
2022-11-02 5:30 ` [RESEND PATCH 4/4] scsi:ufs:add fbo functionality Jiaming Li
2022-11-02 8:53 ` Avri Altman
2022-11-02 20:26 ` kernel test robot
2022-11-02 8:47 ` [RESEND PATCH 0/4] Implement File-Based optimization functionality Christoph Hellwig
2022-11-03 6:11 ` Juhyung Park [this message]
2022-11-04 12:37 ` Matias Bjørling
2022-11-05 5:22 ` Juhyung Park
2022-11-09 12:31 ` Christoph Hellwig
2022-11-02 15:24 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c5948336-19fc-ddd3-bc34-aba2d1b02302@gmail.com \
--to=qkrwngud825@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bvanassche@acm.org \
--cc=hch@infradead.org \
--cc=lijiaming3@xiaomi.com \
--cc=lijiaming3@xiaomi.corp-partner.google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox