Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Jan 2005 12:25:16 +0100
From:      "Daniel Eriksson" <daniel_k_eriksson@telia.com>
To:        <freebsd-current@freebsd.org>
Cc:        =?iso-8859-1?Q?'S=F8ren_Schmidt'?= <sos@DeepCore.dk>
Subject:   A few CURRENT problems
Message-ID:  <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAFq8e/92cLk6Q1zpeIhImOAEAAAAA@telia.com>

Next in thread | Raw E-Mail | Index | Archive | Help

Here are four issues I currently have with CURRENT:

* Mounting a filesystem async no longer seems to work. After mounting a
filesystem like this: "mount -o noatime,async /dev/da1s1d
/some/mount/point", mount does not report the filesystem as being mounted
async: "/dev/da1s1d on /some/mount/point (ufs, local, noatime,
soft-updates)"
I have not had time to verify if the filesystem is actually mounted async or
not, or if it is just a missing attribute output in the list produced by
"mount". I don't know exactly when this stopped "working", but the newmount
commit is my prime suspect. I do remember seeing "async" listed as a
filesystem attribute ~2 months ago.

* Unmounting devfs fails during shutdown, at least when you have it mounted
more than once.
Mounting and configuring a second devfs on a machine like this:
  mount_devfs devfs /jail/dev
  devfs -m /jail/dev rule apply hide
  devfs -m /jail/dev rule apply path null unhide
  devfs -m /jail/dev rule apply path zero unhide
  devfs -m /jail/dev rule apply path random unhide
  devfs -m /jail/dev rule apply path urandom unhide
Results in this during shutdown:
  Syncing disks, vnodes remaining...2 2 2 2 2 2 2 0 0 0 0 0 0 0 0 0 done
  All buffers synced.
  unmount of /jail/dev failed (45)
  unmount of /dev failed (45)
This worked fine until a few days ago. If you cannot replicate it, in my
setup the /jail filesystem is a gbde encrypted filesystem (if that makes any
difference).

* When running fsck on a filesystem it reports where the filesystem was last
mounted. This information is no longer updated. It has been broken at least
2 weeks, maybe more.

* Creating arrays bigger than 1TB with ataraid still doesn't work. The
command ("atacontrol create RAID0 128 ad4 ad5 ad6 ad7 ad8 ad9", where all
the discs are 200GB) runs without any problems, but the resulting array has
an invalid size (amazingly huge). Creating an array on the same discs using
geom_stripe works just fine. I haven't tested this for a few weeks, but I
also haven't seen any commits that might fix it. I really should add this to
the PR database...

/Daniel Eriksson




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAFq8e/92cLk6Q1zpeIhImOAEAAAAA>