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
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).
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 that being able
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
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
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
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 in
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
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
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
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
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 to
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 are data
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
16 matches
Mail list logo
