michael schuster wrote: > Charles Soto wrote: > >> On 6/27/08 8:55 AM, "Mark J Musante" <[EMAIL PROTECTED]> wrote: >> >> >>> On Fri, 27 Jun 2008, wan_jm wrote: >>> >>> >>>> the procedure is follows: >>>> 1. mkdir /tank >>>> 2. touch /tank/a >>>> 3. zpool create tank c0d0p3 >>>> this command give the following error message: >>>> cannot mount '/tank': directory is not empty; >>>> 4. reboot. >>>> then the os can only be login in from console. does it a bug? >>>> >>> No, I would not consider that a bug. >>> >> Why? >> > > well ... why would it be a bug? > > zfs is just making sure that it's not accidentally "hiding" anything by > mounting something on a non-empty mountpoint; as you probably know, > anything that is in a directory is invisible if that directory is used as a > mountpoint for another filesystem. > Yes, but that is the opposite of decades of UNIX behavior, so it's not surprising that it's unexpected for many people. > zfs cannot know whether the mountpoint contains rubbish or whether the > mountpoint property is incorrect, therefore the only sensible thing to do > is to not mount an FS if the mountpoint is non-empty. > > to quote Renaud: > > >> This is an expected behavior. filesystem/local is supposed to mount all >> ZFS filesystems. If it fails then filesystem/local goes into maintenance >> and network/inetd cannot start. >> Shouldn't the other services really only be dependent on system filesystems being mounted? Or possibly all filesystems in the 'root' zfs pool?
I consider it a bug if my machine doesn't boot up because one single, non-system and non-mandatory, FS has an issue and doesn't mount. The rest of the machine should still boot and function fine. -Kyle _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
