On Thu, Jul 20, 2023 at 09:55:22AM +0200, Martin Steigerwald wrote:
>
> I thought that nowadays a cache flush would be (almost) a no-op in the
> case the storage receiving it is backed by such reliability measures.
> I.e. that the hardware just says "I am ready" when having the I/O
> request in
On Wed, Jul 19, 2023 at 12:51:39PM +0200, Kai Tomerius wrote:
> > In answer to Kai's original question, the setup that was described
> > should be fine --- assuming high quality hardware.
>
> I wonder how to judge that ... it's an eMMC supposedly complying to
> some JEDEC standard, so it *should*
On Wed, Jul 19, 2023 at 08:22:43AM +0200, Martin Steigerwald wrote:
>
> Is "nobarrier" mount option still a thing? I thought those mount options
> have been deprecated or even removed with the introduction of cache flush
> handling in kernel 2.6.37?
Yes, it's a thing, and if your server has a U
On Tue, Jul 18, 2023 at 10:04:55AM -0300, Alan C. Assis wrote:
>
> You are right, for NAND there is an old (but gold) presentation here:
>
> https://elinux.org/images/7/7e/ELC2009-FlashFS-Toshiba.pdf
>
> UBIFS and YAFFS2 are the way to go.
This presentation is specifically talking about flash d
On Wed, Jan 04, 2023 at 01:22:06PM -0800, Sarthak Kukreti wrote:
> > How expensive is this expected to be? Is this why you wanted a separate
> > mode flag?
>
> Yes, the exact latency will depend on the stacked block devices and
> the fragmentation at the allocation layers.
>
> I did a quick test
Hmmm. I think this patch should fix your issues.
If the journal has been aborted (which happens as part of the
shutdown, we will never write out the commit block --- so it should be
fine to skip the writeback of any dirty inodes in data=ordered mode.
BTW, if you know that the file system is g
On Tue, May 17, 2022 at 10:10:48AM +0200, Christoph Hellwig wrote:
> I'm a little surprised about all this activity.
>
> I though the conclusion at LSF/MM was that for Linux itself there
> is very little benefit in supporting this scheme. It will massively
> fragment the supported based of device
On Thu, Feb 10, 2022 at 06:30:23PM -0800, Qing Wang wrote:
> From: Wang Qing
>
> It is better to use time_is_xxx() directly instead of jiffies judgment
> for understanding.
Hi Wang,
"judgement" doesn't really make sense as a description to an English
speaker. The following a commit desription
On Thu, Nov 04, 2021 at 12:04:43PM -0700, Darrick J. Wong wrote:
> > Note that I've avoided implementing read/write fops for dax devices
> > partly out of concern for not wanting to figure out shared-mmap vs
> > write coherence issues, but also because of a bet with Dave Hansen
> > that device-dax
On Wed, Oct 13, 2021 at 07:10:38AM +0200, Christoph Hellwig wrote:
> Use the sb_bdev_nr_blocks helper instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Theodore Ts'o
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
(Hmm, why did you cc linux-km on this report? I would have thought
dm-devel would have made more sense?)
On Tue, Apr 27, 2021 at 04:15:39PM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 21175ca434c5d49509b73cf473618b01b0b85437 ("ext4: m
We shouldn't need to hold the lock while are just tearing down and
freeing the whole metadata pool structure.
Signed-off-by: Theodore Ts'o
---
drivers/md/dm-thin-metadata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-thin-metadata.c b/drivers/md/
tio pmem and ext4.
>
> Signed-off-by: Pankaj Gupta
> Reviewed-by: Jan Kara
Acked-by: Theodore Ts'o
On Thu, Nov 16, 2017 at 03:32:05PM -0700, Chris Murphy wrote:
>
> XFS by default does metadata csums. But ext4 doesn't use it for either
> metadata or the journal by default still, it is still optional. So for
> now it mainly benefits XFS.
Metadata checksums are enabled by default in the version
On Mon, Jan 09, 2017 at 04:11:08PM +0100, Zdenek Kabelac wrote:
>
> You have the case were application will write to 'different' filesystem,
> while in other cases user will be able to continue to use their filesystem
> and cause irreparable filesystem damage (whatever you want to believe
> is fai
On Thu, Sep 29, 2016 at 01:45:41PM +0200, SF Markus Elfring wrote:
> > We have no hope of fixing Markus' homegrown coccinelle script.
>
> I have got an other impression. I see further possibilities
> to clarify involved communication and software development challenges
> for a few source code sear
On Wed, Sep 28, 2016 at 05:40:14PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 28 Sep 2016 14:54:39 +0200
>
> Adjust a jump label according to the current Linux coding style convention.
In what bizzaro world is the "current Linux coding style convention"
> -
> -error:
>
On Wed, Sep 28, 2016 at 05:42:28PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 28 Sep 2016 15:21:18 +0200
>
> Adjust jump labels according to the current Linux coding style convention.
>
> -
> -out:
> +set_memory:
> /* Hex key string not needed after here, so wipe i
18 matches
Mail list logo
