Rudolf Potucek wrote:
once you break the model where a snapshot is a point-in-time picture, all sorts
of bad things can happen. You've changed a fundamental assumption of
snapshots, and this then impacts how we view them from all sorts of angles;
it's a huge loss to trade away for a very sma
> NO. Snapshotting is sacred
LOL!
Ok, ok, I admit that snapshotting the whole ZFS root filesystem (yes, we have
ZFS root in production, oops) instead of creating individual snapshots for
*each* individual ZFS is against the code of good sysadmin-ing. I bow to the
developer gods and will only
Rudolf Potucek wrote:
It seems like the appropriate solution would be to
have a tool that
allows removing a file from one or more snapshots
at the same time as
removing the source ...
That would make them not really snapshots. And such
a tool would have
to "fi
> > It seems like the appropriate solution would be to
> have a tool that
> > allows removing a file from one or more snapshots
> at the same time as
> > removing the source ...
>
> That would make them not really snapshots. And such
> a tool would have
> to "fix" clones too.
While I concur tha
Chris Ridd wrote:
On 1 Oct 2009, at 19:34, Andrew Gabriel wrote:
Pick a file which isn't in a snapshot (either because it's been
created since the most recent snapshot, or because it's been
rewritten since the most recent snapshot so it's no longer sharing
blocks with the snapshot version).
On 1 Oct 2009, at 19:34, Andrew Gabriel wrote:
Pick a file which isn't in a snapshot (either because it's been
created since the most recent snapshot, or because it's been
rewritten since the most recent snapshot so it's no longer sharing
blocks with the snapshot version).
Out of curiosi
Rudolf Potucek wrote:
Hmm ... I understand this is a bug, but only in the sense that the message is
not sufficiently descriptive. Removing the file from the source filesystem will
not necessarily free any space because the blocks have to be retained in the
snapshots.
and if it's in a snapsho
On Thu, Oct 01, 2009 at 11:03:06AM -0700, Rudolf Potucek wrote:
> Hmm ... I understand this is a bug, but only in the sense that the
> message is not sufficiently descriptive. Removing the file from the
> source filesystem will not necessarily free any space because the
> blocks have to be retained
Hmm ... I understand this is a bug, but only in the sense that the message is
not sufficiently descriptive. Removing the file from the source filesystem will
not necessarily free any space because the blocks have to be retained in the
snapshots. The same problem exists for zeroing the file with
It's probably this bug:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6453407
We've been affected by the same problem on our X4500 Thumpers. Although the
bug report claims a fix was delivered in solaris_nevada(snv_70), I've yet to
see an official patch released for it (we run Sola
I wonder if one couldln't reduce (but probably not eliminate) the likelihood
of this sort of situation by setting refreservation significantly lower than
reservation?
Along those lines, I don't see any property that would restrict the number
of concurrent snapshots of a dataset :-( I think that
Great point. Hadn't thought of it in that way.
I haven't tried truncating a file prior to trying
to remove it. Either way though, I think it is a
bug if once the filesystem fills up, you can't remove
a file.
Brad
On Thu, 2008-06-05 at 21:13 -0600, Keith Bierman wrote:
> On Jun 5, 2008, at 8:58
> On Thu, Jun 05, 2008 at 09:13:24PM -0600, Keith
> Bierman wrote:
> > On Jun 5, 2008, at 8:58 PM 6/5/, Brad Diggs
> wrote:
> > > Hi Keith,
> > >
> > > Sure you can truncate some files but that
> effectively corrupts
> > > the files in our case and would cause more harm
> than good. The
> > > onl
On Thu, Jun 05, 2008 at 09:13:24PM -0600, Keith Bierman wrote:
> On Jun 5, 2008, at 8:58 PM 6/5/, Brad Diggs wrote:
> > Hi Keith,
> >
> > Sure you can truncate some files but that effectively corrupts
> > the files in our case and would cause more harm than good. The
> > only files in our volume
On Jun 5, 2008, at 8:58 PM 6/5/, Brad Diggs wrote:
> Hi Keith,
>
> Sure you can truncate some files but that effectively corrupts
> the files in our case and would cause more harm than good. The
> only files in our volume are data files.
>
So an rm is ok, but a truncation is not?
Seems odd
On Jun 4, 2008, at 10:40 AM, Brad Diggs wrote:
>
> At this point, the only way in which I can free up sufficient
> space to remove either file is to first remove the snapshot.
Can't you just truncate a large file or two?
Sadly I lack the time to try your example right now, but I'd have
guess
Hello,
A customer recently brought to my attention that ZFS can get
into a situation where the filesystem is full but no files
can be removed. The workaround is to remove a snapshot and
then you should have enough free space to remove a file.
Here is a sample series of commands to reproduce th
17 matches
Mail list logo
