Re: patch for ext2fs unmount problem at shutdown

From: Don Lewis (truckman_at_FreeBSD.org)
Date: 09/06/05

  • Next message: Boris Samorodov: "Re: to commit patch for share/examples/etc/make.conf to remove -O2 warnings" 
    Date: Tue, 6 Sep 2005 02:06:40 -0700 (PDT)
To: phk@haven.freebsd.dk

    On 6 Sep, Poul-Henning Kamp wrote:
    > In message <200509060841.j868fj1I032057@gw.catspoiler.org>, Don Lewis writes:
    >
    >>I suspect both that is one possible reason, and another reason would be
    >>to avoid marking the file system clean if any writes timed out.
    >
    > In that case the unmount should fail, otherwise the filesystem is
    > buggy.
    >
    >>> I think we should do away with the nbusy check, including the 35
    >>> lines of softupdate magic and call vfs_unmountall() in all circumstances
    >>> (but retain the check for !cold, RB_NOSYNC and panic).
    >>>
    >>> Instead we should add a flag to VFS_UNMOUNT that means "don't hang
    >>> forever" and use that in vfs_unmountall().
    >>
    >>That makes sense longer term, but for quite some time we've had a number
    >>of users who have been rather unhappy to find out that every time they
    >>reboot with a mounted ext2fs file system that *all* of their file
    >>systems are marked dirty and require attention from fsck.
    >
    > I am really not keen on adding more magic features to the buffer cache
    > if we can get the same effect by taking away code.

    I'm not especially thrilled about it either since the buffer cache code
    is one of the parts of the kernel that I understand the least. This
    patch is pretty non-intrusive, though, because it essentially just
    borrows an unused flag bit.

    > Considering that our kernel presently tend to explode violently on
    > disk errors I would say that the nbusy check should just be commented
    > out for now and vfs_unmountall() always tried.

    This might be reasonable to try in HEAD, but I'm not comfortable doing
    it in RELENG_6 and RELENG_5. We've always skipped vfs_unmountall() if
    nbusy != 0, so we don't know what strange and wonderful new failure
    modes we might find if we do it unconditionally. Just auditing the code
    would be a lot of work given the number of file system types we support.

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Boris Samorodov: "Re: to commit patch for share/examples/etc/make.conf to remove -O2 warnings"

    Relevant Pages

    • Re: Accessing disks via their serial numbers.
      ... reason to the contrary these listings should be complete. ... the context of a file system, and file systems aren't supposed to ... permissions on these magic nodes, at the very least I'd have no way to ... that that is even for storage filesystems. ...
      (freebsd-arch)
    • Re: Disk defragmenter in Linux
      ... I possibly could, though it would take some study of the file system, ... Its the only good reason for getting into ... I have made some mistakes writing disc caching code. ... When the size of the file is somewhat larger than the cache can hold, and the whole file gets read repeatedly sequentially, then many caching algorithms thrash badly. ...
      (Fedora)
    • RE: SUSPECT: Re: Directory Size problem
      ... running on muptiple computers and do not keep its queues in one ... the reason for the problem with the space not freeing ... The problem may be identified by rebooting the computer. ... Every file has two counters on it in the file system. ...
      (Fedora)
    • Re: TR 24731 approved
      ... the file system), or just use intmax_t ... they're tied to a specific type, long int. ... just give Microsoft yet another reason to ignore the next ... omitted these functions in their partial POSIX implementations. ...
      (comp.std.c)
    • Re: umass(4)/uhci(4) REALLY slow
      ... > On FreeBSD, it really lags. ... This is probably due to something we're not doing in msdosfs. ... probably your msdosfs file system block size. ... None of the lower levels (buffer cache, driver, usb) ...
      (freebsd-current)