writing to RW-mounted UFS2 snapshots - confirmed.
It was mentioned earlier this week that UFS2 snapshots could somehow be mounted read/write and then written to. I noticed this a few weeks ago but didn't think much of it. I have reproduced this: mksnap_ffs / /snap1 mkdir /snapmount mdconfig -a -t vnode -f /snap1 -u 4 mount -r /dev/md4 /snapmount So far so good ... now enter the mounted snapshot and attempt to write a file: # cd /snapmount/ # touch test touch: test: Read-only file system # This is the expected behavior. However: # # pwd /snapmount # mount -uw /snapmount # touch test # echo sldkfslk >> /snapmount/test # # cat /snapmount/test sldkfslk # This is unexpected. You can successfully mount the snapshot read/write and create and write to files in that snapshot. You can also write to files that existed in the snapshot prior to mounting it read/write. I have confirmed that if you unmount the snapshot and remount it again normally, the created file(s) still exist in it, and any changes made to existing files in the snapshot are persistent as well. I don't know what context this was being discussed in, but this behavior does indeed exist, and I believe it to be a somewhat serious problem. - John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Locking: kern/50827
> > Has anyone looked at this? Does anyone have any comments? > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/50827 > > I don't think you'll ever find anyone interested in file locking > anymore. Since they're all advisory, anyway, you can just implement them > at a higher level in your application. BSD and System V IPC mechanisms > already are very good building blocks here for system-scoped locks. Hrm? I'm sort of confused... file locking is still the best way of doing erm... file locking. A few points: 1) File locking works with any program using the file locking API. Hand-rolled implementations will only work with other programs which use the same hand-rolled routines. 2) File locking works across NFS, so you aren't limited to the local system. 3) There's no simple way of doing per-descriptor locks using BSD and SysV IPC... ie: locks which are automatically released when the file descriptor used to obtain the lock is released. This also of course means programs which core won't leave stale locks laying around. Essentially, implementing locks at a higher level is alway more difficult, usually more prone to problems, and in some cases introduces more overhead than the rest of the program. The only reason I can think of for implementing locks at a higher level is for cross-platform code... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: writing to RW-mounted UFS2 snapshots - confirmed.
> This is unexpected. You can successfully mount the snapshot > read/write and create and write to files in that snapshot. You can > also write to files that existed in the snapshot prior to mounting it > read/write. Perhaps the writing is done from a point where the schg flag is not checked or obeyed? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: writing to RW-mounted UFS2 snapshots - confirmed.
On 01/07/2004, at 12:25 PM, Sam Lawrance wrote: This is unexpected. You can successfully mount the snapshot read/write and create and write to files in that snapshot. You can also write to files that existed in the snapshot prior to mounting it read/write. Perhaps the writing is done from a point where the schg flag is not checked or obeyed? While this may not be "expected" behavior, I am curious why this is something that should be prevented, rather than verified for correctness? By "correct" I mean, that the copy on write process is performed correctly and modifications made to the snapshot don't modify the underlying filesystem elements also. To me this has the potential to allow snapshots to be used in reverse as a sort of an "undo drive", similar to unionfs, where you can make changes to a snapshot without the changes being permanently applied to the live filesystem. This might be useful for testing an upgrade or database recovery on a "staging" snapshot before attempting to modify the real thing. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ / Quinton Dolan - [EMAIL PROTECTED] __ __/ / / __/ / / /__ / _// /Gold Coast, QLD, Australia __/ __/ __/ / / - /Ph: +61 419 729 806 ___ / _\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and MacOS
On 30/06/2004, at 4:40 PM, Chris Zumbrunn wrote: On 30. Jun 2004, at 3:01, Alasdair Lumsden wrote: While Mach is derived from 4.3BSD (circa 1986~1988), there's been about 15 years worth of divergence since then. For example, FreeBSD is monolithic while Mach is more micro-kernel based. Also the driver models are quite different, eg Darwin uses IOKit (Object Oriented driver interface model). From Apple's webpages previewing Tiger: "The upgraded kernel, based on FreeBSD 5.x, provides optimised resource locking for better scalability across multiple processors, support for 64-bit memory pointers through the System library and standards-based access control lists." http://www.apple.com.au/macosx/tiger/unix.html Some of the newer code in Darwin is "based on FreeBSD 5.x" yes, but the monolithic FreeBSD kernel (as a whole) is not one of them. Instead apple has targeted the "interesting" bits and imported these pieces of the kernel as discrete components into Darwin (they are implemented this way anyway). Darwin still uses a Mach kernel design, although Apple has made some significant modifications to its implementation to reduce message passing overhead and latency etc, making it something of a hybrid and no longer a pure micro-kernel. As a result the Darwin Mach kernel is not the traditional Mach mix of userspace/kernelspace RPC connected components, instead the kernel is linked into a single address space, using kernel extensions (loadable modules) in a similar way FreeBSD does. However these extensions are implemented using a highly object oriented API (IOKit) for interacting with the kernel, instead of the traditional struct passing procedural approach used in FreeBSD. The portions of the FreeBSD kernel that Apple have adopted can be found as part of the XNU project (the darwin kernel) from Apple's Opensource website http://www.opensource.apple.com/darwinsource/ The CVS tags should still be intact on the files in question. While FreeBSD provides a sizable chunk of Darwin's BSDness, it still has a decent amount of legacy NeXT/BSD code in it as well. Some of the things that have been adopted from FreeBSD/NetBSD in the Darwin kernel include: Crypto support Filesystem support for CD9660, DEVFS, NFS, VFS, MEMDEV (Curiously this doesn't include UFS/FFS support) IP & IPV6 TCP stack support including BPF & IPFW Most of the BSD/Posix/SYSV system calls (sysctl, fork, exec, ktrace, mmap, etc) and corresponding MAN pages. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ / Quinton Dolan - [EMAIL PROTECTED] __ __/ / / __/ / / /__ / _// /Gold Coast, QLD, Australia __/ __/ __/ / / - /Ph: +61 419 729 806 ___ / _\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
