[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50198C83.4000500@oracle.com>
Date: Wed, 01 Aug 2012 15:07:31 -0500
From: Dave Kleikamp <dave.kleikamp@...cle.com>
To: Tino Reichardt <list-linux-fsdevel@...ilk.de>
CC: jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [Jfs-discussion] [PATCH] fs/jfs: TRIM support for JFS Filesystem
On 08/01/2012 02:29 PM, Tino Reichardt wrote:
> * Dave Kleikamp <dave.kleikamp@...cle.com> wrote:
>> On 07/28/2012 06:08 AM, Tino Reichardt wrote:
>>> + tt->nblocks = 0; /* mark the current end */
>>> + for (tt = totrim; tt->nblocks != 0; tt++) {
>>> + if (!(JFS_SBI(sb)->flag & JFS_DISCARD)) {
>>> + /* not needed, when online discard is used */
>>
>> Why enter the function at all if JFS_DISCARD is set? But is this really
>> true? Removing files or file fragments that are smaller than
>> minblks_trim will fail to discard them dynamically.
>
> The other FS can also trim via fstrim(8) when mounted with discard
> option :) It is important, that a user can discard all free blocks, even
> when mounting with discard option. The FS could also be mounted several
> times without discard option, and then there are some ranges, where the
> device isn't informed about these ranges. So the batched discard ioctl()
> is then the only way to change that.
>
>
> The comment there was also a bit updated, here is it:
>
> /* when mounted with online discard, dbFree() will
> * call jfs_issue_discard() itself */
Ah. This comments makes it clear. I was forgetting that dbFree will
handle this.
Thanks,
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists