Searched hist:195938 (Results 1 - 5 of 5) sorted by relevance
| /freebsd-10.3-release/etc/rc.d/ | ||
| H A D | hostid_save | 195938 Wed Jul 29 05:33:36 MDT 2009 pjd Currently there is a problem with fscking UFS file systems created on top of ZVOLs. The problem is that rc.d/fsck runs before rc.d/zfs. The latter makes ZVOLs to appear in /dev/. In such case rc.d/fsck cannot find devfs entry and aborts. We cannot simply move rc.d/zfs before rc.d/fsck, because we first want kern.hostid to be configured (by rc.d/hostid). If we won't wait (hostid will be 0) we can reuse disks which are in use by different systems (eg. in SAN/NAS environment). We also cannot move rc.d/hostid before rc.d/fsck, because rc.d/hostid on first system start stores generated kern.hostuuid in /etc/hostid file, so it needs root file system to be mounted read-write. The fix is to split rc.d/hostid so that rc.d/hostid (which will now run before rc.d/fsck) only generates hostid and sets up sysctls, but doesn't touch root file system and rc.d/hostid_save (which is run after rc.d/root) and only creates /etc/hostid file. With that in place, we can move ZVOL initialization to dedicated rc.d/zvol script which runs before rc.d/fsck. PR: conf/120194 Reported by: James Snow <snow@teardrop.org> Reviewed by: brooks Approved by: re (kib) MFC after: 2 weeks |
| H A D | zfs | diff 195938 Wed Jul 29 05:33:36 MDT 2009 pjd Currently there is a problem with fscking UFS file systems created on top of ZVOLs. The problem is that rc.d/fsck runs before rc.d/zfs. The latter makes ZVOLs to appear in /dev/. In such case rc.d/fsck cannot find devfs entry and aborts. We cannot simply move rc.d/zfs before rc.d/fsck, because we first want kern.hostid to be configured (by rc.d/hostid). If we won't wait (hostid will be 0) we can reuse disks which are in use by different systems (eg. in SAN/NAS environment). We also cannot move rc.d/hostid before rc.d/fsck, because rc.d/hostid on first system start stores generated kern.hostuuid in /etc/hostid file, so it needs root file system to be mounted read-write. The fix is to split rc.d/hostid so that rc.d/hostid (which will now run before rc.d/fsck) only generates hostid and sets up sysctls, but doesn't touch root file system and rc.d/hostid_save (which is run after rc.d/root) and only creates /etc/hostid file. With that in place, we can move ZVOL initialization to dedicated rc.d/zvol script which runs before rc.d/fsck. PR: conf/120194 Reported by: James Snow <snow@teardrop.org> Reviewed by: brooks Approved by: re (kib) MFC after: 2 weeks |
| H A D | zvol | 195938 Wed Jul 29 05:33:36 MDT 2009 pjd Currently there is a problem with fscking UFS file systems created on top of ZVOLs. The problem is that rc.d/fsck runs before rc.d/zfs. The latter makes ZVOLs to appear in /dev/. In such case rc.d/fsck cannot find devfs entry and aborts. We cannot simply move rc.d/zfs before rc.d/fsck, because we first want kern.hostid to be configured (by rc.d/hostid). If we won't wait (hostid will be 0) we can reuse disks which are in use by different systems (eg. in SAN/NAS environment). We also cannot move rc.d/hostid before rc.d/fsck, because rc.d/hostid on first system start stores generated kern.hostuuid in /etc/hostid file, so it needs root file system to be mounted read-write. The fix is to split rc.d/hostid so that rc.d/hostid (which will now run before rc.d/fsck) only generates hostid and sets up sysctls, but doesn't touch root file system and rc.d/hostid_save (which is run after rc.d/root) and only creates /etc/hostid file. With that in place, we can move ZVOL initialization to dedicated rc.d/zvol script which runs before rc.d/fsck. PR: conf/120194 Reported by: James Snow <snow@teardrop.org> Reviewed by: brooks Approved by: re (kib) MFC after: 2 weeks |
| H A D | hostid | diff 195938 Wed Jul 29 05:33:36 MDT 2009 pjd Currently there is a problem with fscking UFS file systems created on top of ZVOLs. The problem is that rc.d/fsck runs before rc.d/zfs. The latter makes ZVOLs to appear in /dev/. In such case rc.d/fsck cannot find devfs entry and aborts. We cannot simply move rc.d/zfs before rc.d/fsck, because we first want kern.hostid to be configured (by rc.d/hostid). If we won't wait (hostid will be 0) we can reuse disks which are in use by different systems (eg. in SAN/NAS environment). We also cannot move rc.d/hostid before rc.d/fsck, because rc.d/hostid on first system start stores generated kern.hostuuid in /etc/hostid file, so it needs root file system to be mounted read-write. The fix is to split rc.d/hostid so that rc.d/hostid (which will now run before rc.d/fsck) only generates hostid and sets up sysctls, but doesn't touch root file system and rc.d/hostid_save (which is run after rc.d/root) and only creates /etc/hostid file. With that in place, we can move ZVOL initialization to dedicated rc.d/zvol script which runs before rc.d/fsck. PR: conf/120194 Reported by: James Snow <snow@teardrop.org> Reviewed by: brooks Approved by: re (kib) MFC after: 2 weeks |
| H A D | Makefile | diff 195938 Wed Jul 29 05:33:36 MDT 2009 pjd Currently there is a problem with fscking UFS file systems created on top of ZVOLs. The problem is that rc.d/fsck runs before rc.d/zfs. The latter makes ZVOLs to appear in /dev/. In such case rc.d/fsck cannot find devfs entry and aborts. We cannot simply move rc.d/zfs before rc.d/fsck, because we first want kern.hostid to be configured (by rc.d/hostid). If we won't wait (hostid will be 0) we can reuse disks which are in use by different systems (eg. in SAN/NAS environment). We also cannot move rc.d/hostid before rc.d/fsck, because rc.d/hostid on first system start stores generated kern.hostuuid in /etc/hostid file, so it needs root file system to be mounted read-write. The fix is to split rc.d/hostid so that rc.d/hostid (which will now run before rc.d/fsck) only generates hostid and sets up sysctls, but doesn't touch root file system and rc.d/hostid_save (which is run after rc.d/root) and only creates /etc/hostid file. With that in place, we can move ZVOL initialization to dedicated rc.d/zvol script which runs before rc.d/fsck. PR: conf/120194 Reported by: James Snow <snow@teardrop.org> Reviewed by: brooks Approved by: re (kib) MFC after: 2 weeks |
Completed in 108 milliseconds