Re: kqueue LOR
On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
Hi,
the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1
with relatively recent kernel, from last week or so.
--
VH
+lock order reversal:
+ 1st 0xc537f300 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547
+ 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @
/usr/src/sys/ufs/ufs/ufs_vnops.c:138
+KDB: stack backtrace:
+kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at
kdb_backtrace+0x2f
+witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at
witness_checkorder+0x5fe
+_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at _mtx_lock_flags+0x32
+ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at
ufs_itimes+0x6c
+ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at
ufs_getattr+0x20
+VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at
VOP_GETATTR_APV+0x3a
+filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75
+knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75
+VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at
VOP_WRITE_APV+0x148
+vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at vn_write+0x201
+dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,,...) at dofilewrite+0x84
+kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65
+write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f
+syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295
+Xint0x80_syscall() at Xint0x80_syscall+0x1f
+--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = 0xbfbfea1c,
ebp = 0xbfbfea48 ---
Thank you for the report. The LOR is caused by my commit into
sys/ufs/ufs/ufs_vnops.c, rev. 1.280.
What application you run that triggers the LOR ? Patch below is one
possible approach to fixing it.
Index: kern/vnode_if.src
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/vnode_if.src,v
retrieving revision 1.84
diff -u -r1.84 vnode_if.src
--- kern/vnode_if.src 13 Nov 2006 05:51:22 - 1.84
+++ kern/vnode_if.src 26 Nov 2006 15:20:44 -
@@ -164,6 +164,16 @@
};
+%% getattrfast vp L L L
+
+vop_getattrfast {
+ IN struct vnode *vp;
+ OUT struct vattr *vap;
+ IN struct ucred *cred;
+ IN struct thread *td;
+};
+
+
%% setattr vp E E E
%! setattr postvop_setattr_post
Index: kern/vfs_default.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/vfs_default.c,v
retrieving revision 1.135
diff -u -r1.135 vfs_default.c
--- kern/vfs_default.c 13 Nov 2006 05:51:22 - 1.135
+++ kern/vfs_default.c 26 Nov 2006 15:20:44 -
@@ -62,6 +62,7 @@
static int vop_nolookup(struct vop_lookup_args *);
static int vop_nostrategy(struct vop_strategy_args *);
+static int vop_stdgetattrfast(struct vop_getattrfast_args *);
/*
* This vnode table stores what we want to do if the filesystem doesn't
@@ -96,6 +97,7 @@
.vop_revoke = VOP_PANIC,
.vop_strategy = vop_nostrategy,
.vop_unlock = vop_stdunlock,
+ .vop_getattrfast = vop_stdgetattrfast,
};
/*
@@ -511,6 +513,19 @@
ap-a_sync, ap-a_rtvals);
}
+static int
+vop_stdgetattrfast(ap)
+ struct vop_getattrfast_args /* {
+ struct vnode *vp;
+ struct vattr *vap;
+ struct ucred *cred;
+ struct thread *td;
+ } */ *ap;
+{
+
+ return VOP_GETATTR(ap-a_vp, ap-a_vap, ap-a_cred, ap-a_td);
+}
+
/*
* vfs default ops
* used to fill the vfs function table to get reasonable default return values.
Index: kern/vfs_subr.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.692
diff -u -r1.692 vfs_subr.c
--- kern/vfs_subr.c 13 Nov 2006 05:51:22 - 1.692
+++ kern/vfs_subr.c 26 Nov 2006 15:20:44 -
@@ -3828,7 +3828,7 @@
return (1);
}
- if (VOP_GETATTR(vp, va, curthread-td_ucred, curthread))
+ if (VOP_GETATTRFAST(vp, va, curthread-td_ucred, curthread))
return (0);
kn-kn_data = va.va_size - kn-kn_fp-f_offset;
Index: ufs/ufs/ufs_vnops.c
===
RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.283
diff -u -r1.283 ufs_vnops.c
--- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 - 1.283
+++ ufs/ufs/ufs_vnops.c 26 Nov 2006 15:20:44 -
@@ -97,6 +97,7 @@
static vop_close_t ufs_close;
static vop_create_tufs_create;
static vop_getattr_t ufs_getattr;
+static vop_getattrfast_t ufs_getattrfast;
static vop_link_t ufs_link;
static int ufs_makeinode(int mode, struct vnode *, struct vnode **, struct
componentname *);
static vop_mkdir_t ufs_mkdir;
Re: kqueue LOR
Kostik Belousov wrote: On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: [...] Thank you for the report. The LOR is caused by my commit into sys/ufs/ufs/ufs_vnops.c, rev. 1.280. What application you run that triggers the LOR ? Patch below is one I have no idea, I just found it in daily summary logs. possible approach to fixing it. [...] -- VH signature.asc Description: OpenPGP digital signature
gmirror and quota corruption
I have a FreeBSD 5.5-STABLE box that is setup with a gmirror RAID 1 using two identical harddrives. I installed quotas on the filesystem by enabling it 'options QUOTA' and rebuilding the kernel. I added userquota to the /etc/fstab for the /usr partition and I added 'enable_quotas=YES' and 'check_quotas=NO' to the /etc/rc.conf file thinking i can get it to build the quota table on the fly instead of it doing that at boot time. The system boots up but as soon as I do any disk access ie 'repquota -a' or write a file to the harddrive, the system hangs. I can still connect to the various services via telnet to their port, but none of them respond. Now that I've disabled quotas I am able to use the system however fsck has reported many various file corruptions and destroyed some of my important system files. Is there a known conflict between gmirror and a quota enabled filesystem? How can I properly set these up? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Message (Your message dated Mon, 27 Nov 2006 06:46:26...)
Your message dated Mon, 27 Nov 2006 06:46:26 -0500 with subject Mail System Error - Returned Mail has been submitted to the moderator of the BUSINESS list: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Proliant ML310 G3 sata raid
I have a HP proliant ML310 G3 server and try to install FreeBSD 6.2 RC1 on it. I have enabled the onboard raid controller and created a mirro of 2 disk on it. Then when it boots it shows one logical drive. But freebsd does not show me the raid it just shows me both drives (ad4 and ad6) if i go to fixit then use the livecd and do atacontrol create mirror ad4 ad6 and then do a reload of sysinstall it shows me ar0 is this the way to do it or am i still not using the hardware raid drive!! regards, Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems unmounting/fssyncking extern UFS filesystem
O. Hartmann wrote: Maybe amd() dismounts to early ... Don't know. Maybe the magic 'sync;sync;sync' before dismounting will help, I'll try it. As far as I know, that's not different from calling sync just once. It might make more sense to put a little sleep between the sync calls, though. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
On Mon, 27 Nov 2006, Brandon S. Allbery KF8NH wrote: On Nov 27, 2006, at 1:09 , Clayton Milos wrote: I just bought a large external hard drive for home backups (500g Western Digital My Book). When I plug it in to my machine (RELENG_6 from about a week ago), the system sees the device just fine: I am very suprised at all that windows would allow you to format a 500G drive into a single 500G FAT32 partition. As far as I am aware windows 2000 and xp will only allow you to format up to a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The other strange thing is tht you are trying to mount /dev/da0 and not /dev/de0s1. How did you format this drive ? It comes formatted FAT32. I bought one last week as well, and tried to mount it to extract the included software before repartitioning. I finally mounted it on an OSX box to copy the software to CDR. [ ... ] I had the same issue with a Fry's $99 special 320GB USB2/FW exernal HDD. Since I need to mount it with WinXP, Linux, and GENERIC FreeBSD, I was somewhat stuck. The way I got around it was to reformat it to ext2 and use the Win32 ext2fs driver from SourceForge. I considered NTFS, but the FreeBSD support for NTFS didn't look practical to use at the time - Jy@ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
secmgr [EMAIL PROTECTED] wrote: As far as I am aware windows 2000 and xp will only allow you to format up to a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The other strange thing is tht you are trying to mount /dev/da0 and not /dev/de0s1. The 32 gb restriction was artificial. You can look it up in the M$ knowledge base. Watch out for the hand waving. FreeBSD and Linux (and probably other cluefull OS's)can handle a 500gb FAT32 drive (assuming intelligent format values) w/o problem. That's not completely correct, at least as far as FreeBSD is concerned (I don't know if and how Linux solves the problem). The basic problem is that FAT doesn't support what UNIX calls inode numbers (sometimes also called fileid). But for a file system to be able to be handled under Free- BSD (and other UNIX systems), files have to be uniquely identified by such inode numbers. To solve that problem, FreeBSD's msdosfs uses a simple hack by assigning a number to each file based on the offset of its directory entry relative to the beginning of the file system. However, if the size of the file system exceeds 128 MB (which is the size of 2^32 directory entries), then those numbers don't fit into a 32 bit inode number anymore. If you try to mount such a file system, it will fail and print the error message disk too big, sorry. If you compile your kernel with MSDOSFS_LARGE, then the kernel uses a different hack to generate appropriate inode numbers: Whenever you access a file, it assigns a number dynamically for this file. That approach works for FAT file systems of unlimited size, but it has two other draw- backs: First, the kernel needs to maintain a table for mapping between files and inode numbers. So, if the file system contains many files, the kernel will need a huge amount of kernel memory which won't be freed until the FS is unmounted (and if you run out of kernel memory, your machine panics). Second, when you unmount and remount the same file system, you might get different inode numbers for your files (because of the dynamic nature), which can confuse certain applications. In particular it breaks NFS because NFS -- being a stateless protocol -- requires constant inode numbers for exports. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Regarding Multiple RAID controller support with FreeBSD 4.11
Hello, I have enabled the support for LSI SAS1068 controller with 4.11 Release, and i compiled the kernel with chnages, it compiles with some work arounds. When booting it successfully detects the LSI controller. I will tell my system config My system is HP Proliant DL380G4, and i have one internal SCSI embedded 6i card, to which i have connected my FreeBSD boot harddisk, and all of my freebsd slices lies there. I have connected two more controllers. One is Smart Array 642 controller, with no drives connected, and LSI SAS 1068 controller with two physical drive connected. Now i didnt create any LUNs with this controller, LSI SAS 1068, Smart Array 6i,Smart Array 642 controllers are connected in PCI slot 1, 3, and 6. I have selected 6i card as the boot Controller in BIOS stage, so initially when the system is powered on, it starts booting from my 6i controller. Without the LSI SAS driver, 6i controller's LUN's slices are mapped with /dev/da0s1a-/dev/da0s1f(with /dev/da0s1a as root partition). When i installed the system the root partition's slice was da0s1a. Now when i compiled the kernel with the support of LSI SAS driver, and i booted it, the LSI card first gets detected and the raw drives connected to LSI controller becomes da0, da1. Then my boot 6i gets detected and the LUN present in this conroller gets da2. When my new kernel tries to mount the root, it always sees the root in da0s1a. So it tells mount failed, and it gives me mountroot prompt. I dont know how to give the root partition option as boot arguments in freebsd boot line, Or is there anything in config file, while we are compiling. How to allocate these device strings dynamically, or how to make our kernel takes the root parition dynamically. I need help regarding this issue. Help me out in figuring out the problem. I have tries disabling the SCSI BIOS in LSI's firrmware config utility, the firmware what am using does not have that support. Thanks and Regards, SaiGanesh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic(): vinvalbuf: dirty bufs: perhaps a ffs_syncvnode bug?
On Thu, Nov 16, 2006 at 09:24:07AM +0100, Rink Springer wrote: Over the night, we reset the shelf in order to activate its new management IP address, causing the /dev/da[12] devices to be temporarily unavailable. This resulted in the following panic on the rather busy mailstorage server (the other server has minor load and was fine): --- (da0:isp0:0:1:0): lost device (da0:isp0:0:1:0): removing device entry (da1:isp0:0:2:0): lost device g_vfs_done():da1s1[WRITE(offset=292316823552, length=16384)]error = 6 g_vfs_done():da1s1[WRITE(offset=240287318016, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=12175362048, length=2048)]error = 6 g_vfs_done():da1s1[WRITE(offset=240287318016, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=18370689024, length=2048)]error = 6 g_vfs_done():da1s1[READ(offset=25829486592, length=512)]error = 6 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 78035 (lmtpd) g_vfs_done():da1s1[WRITE(offset=240287318016, length=1638(da1:isp0:0:2:0): Invalidating pack 4)]error = 6 g_vfs_done():da1s1[READ(offset=13768671232, length=6144)]error = 6 g_vfs_done():da1s1[READ(offset=102126977024, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=13768671232, length=6144)]error = 6 g_vfs_dpone():da1s1[READ(offset=102319669248, length=16384)]error = 6a nic: vinvalbuf: dirty bufs cpuid = 2 Uptime: 54d15h48m38s When looking at the source code of vinvalbuf(), which calls bufobj_invalbuf(), it seems that this panic is raised after a bufobj still contains dirty data after waiting for it to complete without error. The code can be found at /sys/kern/vfs_subr.c Note that this panic can only occur if vinvalbuf() is called with V_SAVE (save modified data first). The exact condition for the panic is better described as: a bufobj still contains dirty data or still has output in progress after a successful synchronous BO_SYNC operation. bufobj_wwait() cannot return an error unless msleep() fails (e.g. interruptible sleep requested via slpflag and signal occured). If the I/O has failed, bufobj_wwait() will return success. The sync routine called eventually translates to bufsync(), as in /sys/kern/vfs_bio.c, which calls the filesystem's sync routine. It seems as if the return status of vfs_bio_awrite() in ffs_syncvnode() is not checked; all the other parts are checked. I believe this could provoke this panic. There does not seem much point in checking an asynchronous write result anyway, as the I/O is not completed yet. I don't understand well what the code is doing with async writes. For all but the last pass (see further), it will call bawrite() on the buffer, which sets B_ASYNC then calls bwrite(). For the last pass, it calls bwrite() directly (has something cleared B_ASYNC?), and returns an error if it fails. bwrite() itself is an inline function defined in /sys/sys/buf.h, which calls BO_WRITE after some KASSERTs. As the machine is in production use, it was instantly rebooted by a collegue and thus I have no vmcore, backtrace or anything. I therefore hope the information provided here is adequate. Can someone with more FreeBSD-VFS knowledge please look at this? There is another possible problem, from this comment in /sys/ufs/ffs/ffs_vnops.c ffs_syncvnode(): /* * Block devices associated with filesystems may * have new I/O requests posted for them even if * the vnode is locked, so no amount of trying will * get them clean. Thus we give block devices a * good effort, then just give up. For all other file * types, go around and try again until it is clean. */ Actually it just does NIADDR + 1 (four) passes and then gives up. If DIAGNOSTIC is enabled, it will then print the affected vnode, if it is not a disk. This failure is not reflected in ffs_syncvnode()'s return value, so if it occurs when ffs_syncvnode() is called from bufobj_invalbuf(), a panic will result. Suppose ffs_syncvnode() would be changed to return some error in this case. bufobj_invalbuf()/vinvalbuf() will handle a BO_SYNC/ffs_syncvnode() error by aborting with an error return. It seems that in most cases this will cause the operation invoking the vinvalbuf() to fail. However, in at least one case (vm_object_terminate()), the error will be ignored; this may cause old garbage/dangling references? -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mezzanine-card in hp blade bl460c
Hi. I have installed a gb-mezzanine-card in my bl460c and the card is recognized (correctly) as a bge-interface. When I configure it with a valid ip-address status remain no carrier. I have put the cable in two different switches, one managed and one un-managed. The switches do see the link as gbit, but link remains down. pciconf -vl | grep -A 3 -i ^bge [EMAIL PROTECTED]:4:0: class 0x02 card=0x1707103c chip=0c167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet Likewise for bge1. dmesg | grep -i ^bge bge0: Broadcom unknown BCM5714, ASIC rev. 0x9003 irq 16 at device 4.0 on pci17 The mezzanine card has a 5715 chip according to the spec's. regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-RC: Problem with SATA on ASUS Vintage AH-*1*
Hello, The model of this box is actually the ASUS Vintage AH-1, sorry for my error! A niggling annoyance present on this machine is that the on-board serial port defaults to COM2 settings, not COM1, however this may be changed in the BIOS. Here is an excerpt from dmesg which I managed to capture after fixing this: %%% atapci2: AcerLabs M5287 SATA150 controller port 0xec00-0xec0f,0xe880-0xe887,0xe800-0xe80f,0xe480-0xe487,0xe400-0xe41f mem 0xfebff800-0xfebffbff irq 21 at device 31.1 on pci0 atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe400 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 53 atapci2: [MPSAFE] atapci2: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfebff800 atapci2: AHCI controller reset failure device_attach: atapci2 attach returned 6 %%% With 6.2-RC1, the only way I can boot this machine is to use the JMicron controller in my PCI-e slot. The onboard controller simply will not work. There is no way of disabling AHCI support in the BIOS. Using a peripheral card isn't really an acceptable long-term workaround. Perhaps we should consider adding a hint to ata(4) not to use AHCI for situations like this? Has anyone else seen this problem? Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regarding Multiple RAID controller support with FreeBSD 4.11
On Mon, Nov 27, 2006 at 08:07:13PM +0530, V.SriSaiGanesh Venkataramani wrote: When i installed the system the root partition's slice was da0s1a. Now when i compiled the kernel with the support of LSI SAS driver, and i booted it, the LSI card first gets detected and the raw drives connected to LSI controller becomes da0, da1. Then my boot 6i gets detected and the LUN present in this conroller gets da2. You have the ability to specify the bus address in 4.x, I believe. There should be examples of it in GENREIC. I am not sure, but is ROOTDEVICE still required in 4.x? If you have that specified, you can either try to change it to da2s1a, or comment it out and see if the kernel still compiles, and boots as expected once the controllers are identified. Bruce -- I like bad! Bruce BurdenAustin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
Oliver Fromme wrote: secmgr [EMAIL PROTECTED] wrote: As far as I am aware windows 2000 and xp will only allow you to format up to a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The other strange thing is tht you are trying to mount /dev/da0 and not /dev/de0s1. The 32 gb restriction was artificial. You can look it up in the M$ knowledge base. Watch out for the hand waving. FreeBSD and Linux (and probably other cluefull OS's)can handle a 500gb FAT32 drive (assuming intelligent format values) w/o problem. That's not completely correct, at least as far as FreeBSD is concerned (I don't know if and how Linux solves the problem). The basic problem is that FAT doesn't support what UNIX calls inode numbers (sometimes also called fileid). But for a file system to be able to be handled under Free- BSD (and other UNIX systems), files have to be uniquely identified by such inode numbers. To solve that problem, FreeBSD's msdosfs uses a simple hack by assigning a number to each file based on the offset of its directory entry relative to the beginning of the file system. However, if the size of the file system exceeds 128 MB (which is the size of 2^32 directory entries), then those numbers don't fit into a 32 bit inode number anymore. If you try to mount such a file system, it will fail and print the error message disk too big, sorry. If you compile your kernel with MSDOSFS_LARGE, then the kernel uses a different hack to generate appropriate inode numbers: Whenever you access a file, it assigns a number dynamically for this file. That approach works for FAT file systems of unlimited size, but it has two other draw- backs: First, the kernel needs to maintain a table for mapping between files and inode numbers. So, if the file system contains many files, the kernel will need a huge amount of kernel memory which won't be freed until the FS is unmounted (and if you run out of kernel memory, your machine panics). Second, when you unmount and remount the same file system, you might get different inode numbers for your files (because of the dynamic nature), which can confuse certain applications. In particular it breaks NFS because NFS -- being a stateless protocol -- requires constant inode numbers for exports. Best regards Oliver Thanks for the explanation. That helps a lot. Because of the potential panics that were mention, I can understand a reluctance to change the default. But I suspect that (attempting to) mount a large msdosfs disk is a much more common occurrence than using a smaller msdosfs disk over NFS. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rc doesn't see my script on boot
Hello, Everybody
Well, here is what I am doing:
ls -l /usr/local/etc/rc.d
total 30
-r-xr-xr-x 1 root wheel 4744 Nov 13 11:38 apache22
-r-xr-xr-x 1 root wheel 673 Nov 13 14:27 clamav-clamd
-r-xr-xr-x 1 root wheel 722 Nov 13 14:27 clamav-freshclam
-r-xr-xr-x 1 root wheel 1057 Nov 13 14:27 clamav-milter
-r-xr-xr-x 1 root wheel 1254 Nov 13 13:01 gnugk
-r-xr-xr-x 1 root wheel 198 Nov 15 01:17 l2tpd
-r-xr-xr-x 1 root wheel 196 Nov 14 12:35 popa3d
-r-xr-xr-x 1 root wheel 1642 Nov 13 11:19 quagga
-r-xr-xr-x 1 root wheel 4371 Nov 13 14:00 samba
-r-xr-xr-x 1 root wheel 1324 Nov 14 15:20 squid
-r-xr-xr-x 1 root wheel 564 Nov 13 11:19 watchquagga
cat /usr/local/etc/rc.d/l2tpd
#!/bin/sh
#PROVIDE l2tpd
#REQUIRE NETWORKING
. /etc/rc.subr
name=l2tpd
rcvar=`set_rcvar`
command=/usr/local/sbin/${name}
flags=
echo l2tp debug
load_rc_config $name
run_rc_command $1
in rc.conf:
l2tpd_enable=YES
Then after reboot:
ps ax | grep l2tpd
667 v1 RL+0:00.00 grep l2tpd
i.e no l2tpd has been started.
no messages on console, either. My script just got silently skipped.
What's wrong?
--
With best regards,
Gregory Edigarov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems unmounting/fssyncking extern UFS filesystem
Date: Mon, 27 Nov 2006 14:53:06 +0100 (CET) From: Oliver Fromme [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] O. Hartmann wrote: Maybe amd() dismounts to early ... Don't know. Maybe the magic 'sync;sync;sync' before dismounting will help, I'll try it. As far as I know, that's not different from calling sync just once. It might make more sense to put a little sleep between the sync calls, though. The traditional mantra was sync sync sync and not sync;sync;sync. The reason was timing. By entering the sync command three times as fast as anyone could type, the sync could reliably complete. That mantra is about 25 years old, so its validity on modern hardware is questionable, but the need for a delay is very real. I would suggest something like: sync sleep 5 -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpYYS68ors84.pgp Description: PGP signature
Re: Large msdosfs disk will not mount on RELENG_6
Richard Coleman wrote: Oliver Fromme wrote: [...] However, if the size of the file system exceeds 128 MB That should be 128 GB, of course. [...] Because of the potential panics that were mention, I can understand a reluctance to change the default. But I suspect that (attempting to) mount a large msdosfs disk is a much more common occurrence than using a smaller msdosfs disk over NFS. Well, the mentioned problems (running out of kernel memory and NFS export difficulties) can occur with msdosfs file systems of any size, including ones that are smaller than 128 GB. It would be really annoying to not be able to mount a USB stick with a lot of files on a machine with small RAM (it could panic the machine without warning). On the other hand, the default (no MSDOSFS_LARGE) is safe for any number of files, i.e. you cannot panic the system, but you're limited to 128 GB file system size. (Well, you _can_ cause a panic with certain broken file systems, but that's a different story.) It's really chosing the lesser of two evils, but which one is the lesser? The answer depends on whom you ask. :-) I think the best solution would be to convert the kernel option into a mount option, so you can select your evil at mount time without having to recompile and reboot. Then you would even be able to mount your USB stick with the first hack and -- at the same time -- mount your external big disk with the second hack. Someone would have to code that, of course. I'm afraid I'm not volunteering (lack of time). It shouldn't be fairly easy to code, though: just add a flag to the mount (similar to the existing flag for win95 long file names) that indicates which hack to use, and select the apropriate hack at runtime, basically replacing the current #ifdef with an ordinary if(...). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc doesn't see my script on boot
Gregory Edigarov wrote:
Hello, Everybody
Well, here is what I am doing:
ls -l /usr/local/etc/rc.d
total 30
-r-xr-xr-x 1 root wheel 4744 Nov 13 11:38 apache22
-r-xr-xr-x 1 root wheel 673 Nov 13 14:27 clamav-clamd
-r-xr-xr-x 1 root wheel 722 Nov 13 14:27 clamav-freshclam
-r-xr-xr-x 1 root wheel 1057 Nov 13 14:27 clamav-milter
-r-xr-xr-x 1 root wheel 1254 Nov 13 13:01 gnugk
-r-xr-xr-x 1 root wheel 198 Nov 15 01:17 l2tpd
-r-xr-xr-x 1 root wheel 196 Nov 14 12:35 popa3d
-r-xr-xr-x 1 root wheel 1642 Nov 13 11:19 quagga
-r-xr-xr-x 1 root wheel 4371 Nov 13 14:00 samba
-r-xr-xr-x 1 root wheel 1324 Nov 14 15:20 squid
-r-xr-xr-x 1 root wheel 564 Nov 13 11:19 watchquagga
cat /usr/local/etc/rc.d/l2tpd
#!/bin/sh
#PROVIDE l2tpd
#REQUIRE NETWORKING
. /etc/rc.subr
name=l2tpd
rcvar=`set_rcvar`
command=/usr/local/sbin/${name}
flags=
echo l2tp debug
load_rc_config $name
run_rc_command $1
in rc.conf:
l2tpd_enable=YES
Then after reboot:
ps ax | grep l2tpd
667 v1 RL+0:00.00 grep l2tpd
i.e no l2tpd has been started.
no messages on console, either. My script just got silently skipped.
What's wrong?
It looks like the formatting of the PROVIDE and REQUIRE statements may
be incorrect. Try:
# PROVIDE: l2tpd
# REQUIRE: NETWORKING
(note a single space between the hash mark and PROVIDE/REQUIRE, and the
colon and a single space after PROVIDE/REQUIRE)
-Proto
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc doesn't see my script on boot
Gregory Edigarov wrote: [...] #PROVIDE l2tpd Be sure to get the synatx right. It must look like this: # PROVIDE: l2tpd The PROVIDE line is used to distinguish old-style scripts from rcNG scripts. Therefore it is important that you get the syntax of that line right, or otherwise the script will not be recognized correctly. That's what happened in your case: The PROVIDE line was not recognized, so it was assumed to be an old-style script. Those scripts are only executed if they are executable _and_ have a filename extension .sh. Your script doesn't have that extension, so it was ignored. #REQUIRE NETWORKING That line needs also to be fixed (space, colon). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems unmounting/fssyncking extern UFS filesystem
I realise the original posting was related to amd(8) and NFS is not a normal filesystem but in the interest of trying to stamp out this myth... On Mon, 2006-Nov-27 08:41:19 -0800, Kevin Oberman wrote: The traditional mantra was sync sync sync ... That mantra is about 25 years old, so its validity on modern hardware is questionable, but the need for a delay is very real. For any modern Un*x, it is totally unnecessary. All current Un*x filesystems will automatically flush all buffers as part of the unmount process - specifically, any FS with a 'CLEAN' flag can be guaranteed to do so. I would suggest something like: sync sleep 5 In the specific case of softupdates, this is not adequate to flush all outstanding writes. The sync will flush one level of dependencies but can still leave outstanding writes. 'sleep 5' may or may not be adequate, depending on the amount of dirty cached data. As an experiment, I suggest creating or deleting a FS tree on an otherwise idle system and looking at the 'dirtybuf' value reported by 'systat -v 1'. See how many sync's and how long it takes to get it to blank (0). -- Peter Jeremy pgpxS6pQQXEBP.pgp Description: PGP signature
Re: Problems unmounting/fssyncking extern UFS filesystem
On Tue, Nov 28, 2006 at 05:37:58AM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: All current Un*x filesystems will automatically flush all buffers as part of the unmount process That Depends(tm), partly on what you mean by 'unmount'. With my Nov05 and Jun06 -CURRENT's, I had to take great care to sync and sync and wait and sync and sync filesystems before mount -u -o ro'ing them, because otherwise they'd end up NOT flushing everything, leaving unreferenced stuff around that fsck had to clean up, but only if I ran it manually because mount DID mark the filesystem as clean. I just tried to reproduce it on my last-week -CURRENT, and it no longer does that. Instead, it locked itself into a softdep_waitidle: Failed to flush worklist loop and won't LET me remount r/o (or unmount) the filesystems. Obviously, I should have kept up my now-established habit of sync'ing and waiting a while before un/remounting... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
On Mon, 27 Nov 2006, James Wyatt wrote: On Mon, 27 Nov 2006, Brandon S. Allbery KF8NH wrote: On Nov 27, 2006, at 1:09 , Clayton Milos wrote: I just bought a large external hard drive for home backups (500g Western Digital My Book). When I plug it in to my machine (RELENG_6 from about a week ago), the system sees the device just fine: I am very suprised at all that windows would allow you to format a 500G drive into a single 500G FAT32 partition. As far as I am aware windows 2000 and xp will only allow you to format up to a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The other strange thing is tht you are trying to mount /dev/da0 and not /dev/de0s1. How did you format this drive ? It comes formatted FAT32. I bought one last week as well, and tried to mount it to extract the included software before repartitioning. I finally mounted it on an OSX box to copy the software to CDR. [ ... ] I had the same issue with a Fry's $99 special 320GB USB2/FW exernal HDD. Since I need to mount it with WinXP, Linux, and GENERIC FreeBSD, I was somewhat stuck. The way I got around it was to reformat it to ext2 and use the Win32 ext2fs driver from SourceForge. I considered NTFS, but the FreeBSD support for NTFS didn't look practical to use at the time - Jy@ Sorry to reply to myself, but I forgot to mention that if you're doing tar/zip backups, then FAT32 may be worth the extra memory. If you are doing file backups, then ext2 will better preserve the metadata you want like UID, GID, permissions, etc... as well as avoiding the waste of small files stored in mega-clusters. The ext2fs WinXP driver defaults to having the write-cache disabled, so it's not a high-performance approach - Jy@ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems unmounting/fssyncking extern UFS filesystem
On Mon, 27 Nov 2006 21:19:40 +0100, Matthew D. Fuller [EMAIL PROTECTED] wrote: On Tue, Nov 28, 2006 at 05:37:58AM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: All current Un*x filesystems will automatically flush all buffers as part of the unmount process That Depends(tm), partly on what you mean by 'unmount'. With my Nov05 and Jun06 -CURRENT's, I had to take great care to sync and sync and wait and sync and sync filesystems before mount -u -o ro'ing them, because otherwise they'd end up NOT flushing everything, leaving unreferenced stuff around that fsck had to clean up, but only if I ran it manually because mount DID mark the filesystem as clean. I just tried to reproduce it on my last-week -CURRENT, and it no longer does that. Instead, it locked itself into a softdep_waitidle: Failed to flush worklist loop and won't LET me remount r/o (or unmount) the filesystems. Obviously, I should have kept up my now-established habit of sync'ing and waiting a while before un/remounting... IMHO: Please discuss this on [EMAIL PROTECTED] And read the handbook (http://www.freebsd.org/handbook) about releases/versions/branches. -CURRENT is known to have bugs. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems unmounting/fssyncking extern UFS filesystem
Ronald Klop wrote: On Mon, 27 Nov 2006 21:19:40 +0100, Matthew D. Fuller [EMAIL PROTECTED] wrote: On Tue, Nov 28, 2006 at 05:37:58AM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: All current Un*x filesystems will automatically flush all buffers as part of the unmount process That Depends(tm), partly on what you mean by 'unmount'. With my Nov05 and Jun06 -CURRENT's, I had to take great care to sync and sync and wait and sync and sync filesystems before mount -u -o ro'ing them, because otherwise they'd end up NOT flushing everything, leaving unreferenced stuff around that fsck had to clean up, but only if I ran it manually because mount DID mark the filesystem as clean. I just tried to reproduce it on my last-week -CURRENT, and it no longer does that. Instead, it locked itself into a softdep_waitidle: Failed to flush worklist loop and won't LET me remount r/o (or unmount) the filesystems. Obviously, I should have kept up my now-established habit of sync'ing and waiting a while before un/remounting... IMHO: Please discuss this on [EMAIL PROTECTED] And read the handbook (http://www.freebsd.org/handbook) about releases/versions/branches. -CURRENT is known to have bugs. -- Ronald Klop Amsterdam, The Netherlands One of the fellows herein told me this discussion is subject to STABLE! Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
