tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/kern



In article <Pine.NEB.4.64.0809241934250.10174%ugly.precedence.co.uk@localhost>,
Stephen Borrill  <netbsd%precedence.co.uk@localhost> wrote:
>I'll add a <aol>me too</aol> here.
>
>On Wed, 24 Sep 2008, Thor Lancelot Simon wrote:
>> On Wed, Sep 24, 2008 at 01:19:43PM -0500, David Young wrote:
>>> On Wed, Sep 24, 2008 at 01:46:34PM -0400, Thor Lancelot Simon wrote:
>>>>
>>>> This also breaks products which run from flash with their
>filesystems mounted
>>>> read-only most of the time, but remount them read-write in order to write
>>>> back configuration data when it changes.  That is not an uncommon model
>>>> AFAIK and it poses a fairly major problem for me.
>>>
>>> Your application sounds similar to mine.  I gave up remounting a
>>> read-write filesystem read-only long, long ago, because if I created or
>>> deleted and re-created as few as one or two files, remounted read-only,
>>> and rebooted shortly thereafter, the filesystem had lost the most
>>> recently created files.  I have probably annotated the problem report
>>> with that information.
>>
>> When is "long, long ago"?  We have not updated our sources from the
>NetBSD trunk
>> in about three months, but I haven't seen any sign of this problem. 
>One difference
>> may be that our configuration information is stored in a "repository"
>file and then
>> extracted back into a mounted-on-top memory filesystem early in boot;
>when we remount
>> read-write, typically the only file we update is the repository, after
>which we fsync
>> it and sync the filesystem before remounting r/o.
>
>We write or alter a couple of configuration files, sync and then remount 
>r/o. I've not seen any problems with netbsd-3 or netbsd-4. Is it believed
>that this problem is a regression in -current?

No, it's been there forever. Even thornier is the issue of, having a process
that has an open for write file descriptor open on the fs to be re-mounted.
In that case the remount should fail with EBUSY but last time I checked it
does not.

christos




Home | Main Index | Thread Index | Old Index