linux-kernel - Re: [PATCH 0/5] FAT errors, user space notifications

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] [day] [month] [year] [list]

Message-ID: <87oct5l592.fsf@devron.myhome.or.jp>
Date:	Thu, 04 Jun 2009 00:13:45 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	linux-kernel@...r.kernel.org
Cc:	"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"Hunter Adrian \(Nokia-D\/Helsinki\)" <adrian.hunter@...ia.com>,
	"Bityutskiy Artem \(Nokia-D\/Helsinki\)" <Artem.Bityutskiy@...ia.com>
Subject: Re: [PATCH 0/5] FAT errors, user space notifications

Denis Karpov <ext-denis.2.karpov@...ia.com> writes:

> I realise that, but in this particular case I deal with non-critical data 
> on a large FAT partition and can probably afford certain risk of damaging
> the data. What I can't afford is to spend several minutes fsck'ing huge FAT
> partition on slow SD/MMC media during bootup.
>
> So I choose to optionally receive notification of errors encountered 
> during 'run time' and act upon them.
>
> Otherwise, nothing stops you from doing proper fsck before mounting.

I think fsckless is to add the reliability to fs driver (logging,
softupdate, etc.). Yes, it's not easy, and it needs time. Anyway, I
actually thought about softupdate (and some others) before, I think it's
_not_ nothing.

> IMO, receivng notification of errors is benefitial in any case:
> together with the 1st patch above it gives full flexibility to user space
> to implement fs 'run-time' errors handling policy (at least for FAT,EXT2),
> e.g.:
>
> - do nothing: remount r/o on errors, don't monitor kernel notifications (old/default
>  behavior)
> - remount-ro on errors, get notified; unmount partition, fsck, mount
>   partition back r/w;
> - ignore errors (continue), get notified: unmount the partition later at
> suitable time, fsck, mount back r/w

If this is monitoring interface, I guess it should be more generic. And
I guess it will tell what happened in kernel, not fs_clean. (There is no
guarantee about fs state)

If not, some errors can not be detected by fs driver. User may know some
run-time errors by fs_clean, but some run-time errors is not. So, user
can not trust fs_clean.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/