linux-kernel - Re: EXT4-ish "fixes" in UBIFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49CF6A08.3000704@yandex.ru>
Date:	Sun, 29 Mar 2009 15:31:04 +0300
From:	Artem Bityutskiy <dedekind@...dex.ru>
To:	Kyungmin Park <kmpark@...radead.org>
CC:	Artem.Bityutskiy@...ia.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: EXT4-ish "fixes" in UBIFS

Kyungmin Park wrote:
> I also got these request. the file is empty at rename operatoin in
> case of sudden power off.
> they say it's different from jffs2. in case of jffs2, it points old
> files even though power off.

Right, because JFFS2 is synchronous :-)

> then why is UBIFS different. fix it as before. I said it's not
> filesystem bug. it's expected behaviors.

Right, this is what I've been always thinking. I've always been
thinking the FS gives no guarantees, and if you want a 100%
guarantee, use fsync() before renaming. Frankly, I still think
so. But we'll make ext4-like changes in UBIFS as well to help
the applications which do not do the sync.

> Frankly I'm not sure which one is better. how much filesystem support
> it. but remember that application programmer also don't want to change
> their application when filesystem is changed.
> "The application is not changed, only filesystem is changed. so it's
> filesystem problem, not us"

I hope Linux gurus will put it clearly after all - to fsync() or to
not fsync(). We do need clear rules of the game. For now, I still
assume the following:

1. If applications want atomic update which gives 100% guarantee,
   they should fsync before rename.
2. If the application does not use fsync, FS should try to minimize
   the probability of data loss by running asynchronous write-back
   on rename which unlinks a direntry.
3. All this performance vs. reliability hassle should be solved
   by fixing the FS, by having good defaults, by having a
   "fsync/not fsync" knobs in applications.

Indeed, people mostly talk about ext3, desktops, etc. But there
is also the embedded world, where battery is removed randomly.

But will see where this all leads. I really want clean rules
for this.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
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/