Re: [f2fs-dev] [PATCH] f2fs: compress: support lz4hc compression

Hi Chao. On Mon, Nov 30, 2020 at 8:28 PM Chao Yu wrote: > > Add a new mount option "compress_lz4hc_clevel=%u" to enable lz4hc compress > algorithm and specify the compress level of lz4hc. Wouldn't it be better to introduce a generic mount option like "compress_level=%u" to allow other

Re: [PATCH] ata: Disable queued TRIM for Samsung 860 SSDs

Hi Martin, On Thu, Jul 16, 2020 at 5:53 AM Martin K. Petersen wrote: > I really wish we had some more data to work with :( > > Lacking a proper heuristic I guess we don't have any choice to disable > the feature. But that's sad news for the people who currently don't have > problems since their

Re: [PATCH] ata: Disable queued TRIM for Samsung 860 SSDs

Hi Simon, On Wed, Jul 15, 2020 at 8:13 PM Simon Arlott wrote: > the original justification for > enabling appears to be based on marketing material with no explanation > of what has been changed to make the 860 work properly when the earlier > 840 and 850 both have the same issue. Yes, this was

Re: [PATCH] exfat: implement "quiet" option for setattr

Hi Namjae. Looks like I ported this incorrectly from the previous sdFAT base. I'll fix, test again and send v2. Thanks. On Thu, Jul 2, 2020 at 2:16 PM Namjae Jeon wrote: > > > > > if (((attr->ia_valid & ATTR_UID) && > >!uid_eq(attr->ia_uid, sbi->options.fs_uid)) || @@ -322,6

exfat: request to implement FITRIM ioctl for fstrim

Hi. It has come to my attention that while exfat supports live trim via the discard mount option, it does not implement FITRIM ioctl for fstrim(8). As exfat finally became the R/W cross-platform file-system solution and many flash storages defaulting to exfat, I'd love to see fstrim support

Re: [PATCH] staging: exfat: rebase to sdFAT v2.2.0

Welp, looks like I didn't test debug configs properly. Allow me 1-2 days to work on fixing it for v2. Thanks in advance. On Thu, Sep 19, 2019 at 6:31 AM kbuild test robot wrote: > > Hi Park, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] >

Re: [PATCH] staging: exfat: rebase to sdFAT v2.2.0

On Thu, Sep 19, 2019 at 5:26 AM Greg KH wrote: > That differs from the original exfat code, so something is odd here. I > need some sort of clarification from Samsung as to when they changed the > license in order to be able to relicense these files. We should probably ask Valdis on what

Re: [PATCH] staging: exfat: rebase to sdFAT v2.2.0

Hi Greg, On Thu, Sep 19, 2019 at 5:12 AM Greg KH wrote: > That's a lot of rewriting :( > > How about at least keeping the file names the same to make it easier to > see what happened here? > > Then send a follow-on patch that just does the rename? That's still not quite useful tbh, lemme bring

Re: [PATCH] staging: exfat: add exfat filesystem code to

On Wed, Sep 18, 2019 at 7:09 PM Dan Carpenter wrote: > Use Kconfig. Not just that. There are a lot of non-static functions that's not marked ex/sdfat-specific. (which we would have to clean it up eventually) Even with sdFAT base, there are some non-static functions named as exfat. Figuring out

Re: [PATCH] staging: exfat: add exfat filesystem code to

Hi Dan, On Wed, Sep 18, 2019 at 6:27 PM Dan Carpenter wrote: > Put it in drivers/staging/sdfat/. It'll conflict with the current exfat staging drivers. And moreover, I don't think it makes sense to use sdfat naming in mainline. Samsung uses it since it handles all fat filesystems. >From what I

Re: [PATCH] staging: exfat: add exfat filesystem code to

On Wed, Sep 18, 2019 at 5:33 PM Greg KH wrote: > He did? I do not see a patch anywhere, what is the message-id of it? I'm just repeating myself at this point, but again, I'm more than willing to work on a patch. I just want to make it clear on how should I. > He took the "best known at the

Re: [PATCH] staging: exfat: add exfat filesystem code to

On Tue, Sep 17, 2019 at 2:47 PM Greg KH wrote: > It's the fact that it actually was in a form that could be merged, no > one has done that with the sdfat code :) Well, I'm more than happy to help if you guys are happy with merging the new base. > What fixes? That's what I'm asking here. I

Re: [PATCH] staging: exfat: add exfat filesystem code to

Hi Greg, On Sun, Sep 15, 2019 at 10:54 PM Greg KH wrote: > Note, this just showed up publically on August 12, where were you with > all of this new code before then? :) My sdFAT port, exfat-nofuse and the one on the staging tree, were all made by Samsung. And unless you guys had a chance to

Re: [f2fs-dev] [PATCH] f2fs: Fix bool initialization/comparison

Isn't this bogus? "bool" type in Linux kernel is a typedef to "_Bool" and true/false is defined as 1 and 0 by enum at include/linux/stddef.h. On Sat, Oct 7, 2017 at 11:02 PM, Thomas Meyer wrote: > Bool initializations should use true and false. Bool tests don't need >

Re: [f2fs-dev] [PATCH] f2fs: Fix bool initialization/comparison

Isn't this bogus? "bool" type in Linux kernel is a typedef to "_Bool" and true/false is defined as 1 and 0 by enum at include/linux/stddef.h. On Sat, Oct 7, 2017 at 11:02 PM, Thomas Meyer wrote: > Bool initializations should use true and false. Bool tests don't need > comparisons. > >

Re: [f2fs-dev] [PATCH v4] f2fs: introduce discard_granularity sysfs entry

16 +0800 > Subject: [PATCH] f2fs: fix potential panic during fstrim > > As Ju Hyung Park reported: > > "When 'fstrim' is called for manual trim, a BUG() can be triggered > randomly with this patch. > > I'm seeing this issue on both x86 Desktop and arm64 Android ph

Re: [f2fs-dev] [PATCH v4] f2fs: introduce discard_granularity sysfs entry

3, 2017 at 12:59 AM, Chao Yu wrote: > Hi Park, > > Thanks for the report, could have a try with below patch: > > From 5fa30e8cdcb93f210e25142c48a884be383c6121 Mon Sep 17 00:00:00 2001 > From: Chao Yu > Date: Mon, 2 Oct 2017 02:50:16 +0800 > Subject: [PATCH] f2fs: fix potent

Re: [f2fs-dev] [PATCH v4] f2fs: introduce discard_granularity sysfs entry

When 'fstrim' is called for manual trim, a BUG() can be triggered randomly with this patch. I'm seeing this issue on both x86 Desktop and arm64 Android phone. On x86 Desktop, this was caused during Ubuntu boot-up. I have a cronjob installed which calls 'fstrim -v /' during boot. On arm64

Re: [f2fs-dev] [PATCH v4] f2fs: introduce discard_granularity sysfs entry

When 'fstrim' is called for manual trim, a BUG() can be triggered randomly with this patch. I'm seeing this issue on both x86 Desktop and arm64 Android phone. On x86 Desktop, this was caused during Ubuntu boot-up. I have a cronjob installed which calls 'fstrim -v /' during boot. On arm64