In any case, have you an idea of the way to solve my current problem? I have
450Gb in a deduped dataset I want to destroy, and each tentative I do results
in a machine hang. I just want to destroy a dataset and all of its snapshots!!
I tried unmounting before zfs destroy but had no luck...
Thanks
- Original Message -
> Sorry roy, but reading the post you pointed me
> "meaning about 1,2GB per 1TB stored on 128kB blocks"
> I have 1,5TB and 4 Gb of RAM, and not all of this is deduped.
> Why you say it's *way* too small. It should be *way* enough.
> From the performance point of view, i
Sorry roy, but reading the post you pointed me
"meaning about 1,2GB per 1TB stored on 128kB blocks"
I have 1,5TB and 4 Gb of RAM, and not all of this is deduped.
Why you say it's *way* too small. It should be *way* enough.
>From the performance point of view, it is not a problem, I use that machine
On 7/1/2010 12:23 PM, Lo Zio wrote:
Thanks roy, I read a lot around and also was thinking it was a dedup-related problem.
Although I did not find any indication of how many RAM is enough, and never find
something saying "Do not use dedup, it will definitely crash your server". I'm
using a Dell
- Original Message -
> Thanks roy, I read a lot around and also was thinking it was a
> dedup-related problem. Although I did not find any indication of how
> many RAM is enough, and never find something saying "Do not use dedup,
> it will definitely crash your server". I'm using a Dell Xeo
Thanks roy, I read a lot around and also was thinking it was a dedup-related
problem. Although I did not find any indication of how many RAM is enough, and
never find something saying "Do not use dedup, it will definitely crash your
server". I'm using a Dell Xeon with 4 Gb of RAM, maybe it is no
- Original Message -
> I also have this problem, with 134 if I delete big snapshots the
> server hangs only responding to ping.
> I also have the ZVOL issue.
> Any news about having them solved?
> In my case this is a big problem since I'm using osol as a file
> server...
Are you using ded
I also have this problem, with 134 if I delete big snapshots the server hangs
only responding to ping.
I also have the ZVOL issue.
Any news about having them solved?
In my case this is a big problem since I'm using osol as a file server...
Thanks
--
This message posted from opensolaris.org
__
Hi - was there any progress on this issue?
I'd be interested to know if any bugs were filed regarding it and whether
there's a way to follow up on the progress.
Cheers,
Alasdair
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
> This sounds like yet another instance of
>
> 6910767 deleting large holey objects hangs other I/Os
>
> I have a module based on 130 that includes this fix
> if you would like to try it.
>
> -tim
Hi Tim,
6910767 seems to be about ZVOLs. The dataset here was not a ZVOL. I had a 1,4
TB ZVOL on
On 01/27/10 04:39 AM, erik.ableson wrote:
On 27 janv. 2010, at 12:10, Georg S. Duck wrote:
Hi,
I was suffering for weeks from the following problem:
a zfs dataset contained an automatic snapshot (monthly) that used 2.8 TB of
data. The dataset was deprecated, so I chose to destroy it after
> Server responds to pings, but that's it. All iSCSI, NFS and ssh connections
> are cut.
That's consistent with my findings, adding that SMB is cut as well.
At one vain attempt to destroy the data...@snapshot I got a "[ID 224711
kern.warning] WARNING: Memory pressure: TCP defensive mode on". If
On 27 janv. 2010, at 12:10, Georg S. Duck wrote:
> Hi,
> I was suffering for weeks from the following problem:
> a zfs dataset contained an automatic snapshot (monthly) that used 2.8 TB of
> data. The dataset was deprecated, so I chose to destroy it after I had
> deleted some files; eventually
Hi,
I was suffering for weeks from the following problem:
a zfs dataset contained an automatic snapshot (monthly) that used 2.8 TB of
data. The dataset was deprecated, so I chose to destroy it after I had deleted
some files; eventually it was completely blank besides the snapshot that still
lock
14 matches
Mail list logo
