On Thu, 1 Jul 2004, Q 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 f
On Thu, 1 Jul 2004, Q wrote:
> > 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 sna
On 01/07/2004, at 4:22 PM, Q wrote:
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.
Perh
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
> 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
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 /snapmou
6 matches
Mail list logo
