unionfs kqueue?
Hi, Does unionfs work with kqueue? When I run `tail -f` on a file residing on unionfs with cd9660 underneeth and md+ufs over it, it doesn't detect changes. The changes are immediately visible, just not with tail -f. signature.asc Description: OpenPGP digital signature
Re: unionfs kqueue?
Heya, Does unionfs work with kqueue? When I run `tail -f` on a file residing on unionfs with cd9660 underneeth and md+ufs over it, it doesn't detect changes. The changes are immediately visible, just not with tail -f. Hmm. When you start the tail -f, does the file reside on the cd9660 or already on the md? See if tail -F does a better job. My guess would be that, since you cannot modify a file on any filesystem except the top one, unionfs must change semantics of open so that even opening for writing or appending silently creates a new copy of the file on the top filesystem (if the file didn't reside there already). As tail -f still has the lower-layer file open, it never notices that there's a new file by the name. (this behavior is the same as echo foo foo tail -f foo # in another terminal echo bar bar mv bar foo which also fails to notice the new data) So Far, Karsten BearPerson Behrmann p.s.: this is probably why the -F option was added to tail -- Open source is not about suing someone who sells your software. It is about being able to walk behind him, grinning, and waving free CDs with the equivalent of what he is trying to sell. signature.asc Description: PGP signature
Re: unionfs kqueue?
Karsten Behrmann wrote: Heya, Does unionfs work with kqueue? When I run `tail -f` on a file residing on unionfs with cd9660 underneeth and md+ufs over it, it doesn't detect changes. The changes are immediately visible, just not with tail -f. Hmm. When you start the tail -f, does the file reside on the cd9660 or already on the md? The file resides entirely in the upper layer, in the md. See if tail -F does a better job. Will do. My guess would be that, since you cannot modify a file on any filesystem except the top one, unionfs must change semantics of open so that even opening for writing or appending silently creates a new copy of the file on the top filesystem (if the file didn't reside there already). Yes, AFAIK it does that. As tail -f still has the lower-layer file open, it never notices that there's a new file by the name. Not in my case - there's no such lower-layer file. signature.asc Description: OpenPGP digital signature
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
On Mon, Nov 19, 2007 at 09:02:33AM +0100 I heard the voice of Søren Schmidt, and lo! it spake thus: I'd like to get the final verdict of the attached patch and if it fixes the problem or not. Behind the curve, as usual, I just upgraded one of my systems that's had the problem in the past to RELENG_7 (which has the fix). It's since moved a bunch of data and done a bunch of builds without a hint of trouble, so looks good to me. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overlap in PCI memory ranges
Coleman Kane wrote: Also, the mem resources of the SATA controller are used for AHCI (however, PATA compatibility mode is supported using the port ranges, which is what the controller is forced to do). In addition, the device name string on the SATA controller is only there because I've been fooling with ata-chipset.c (to unsuccessfully attempt to get AHCI working). Reading the MMIO registers in AHCI mode seems to produce Do you have some patches for ata(4)? I don't see in the clean sources where driver can allocate a memory resources for the ATI. As i see from your dmesg driver doesn't use AHCI. situation (a single port SATA controller on a laptop). This is supposed to read a bitmap of the enabled ports on the SATA controller. Please, show your `pciconf -l`. And if you have some patches, show their. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
