2010/12/8 :
> To explain further the slow delete problem:
>
> It is absolutely critical for zfs to manage the incoming data rate.
> This is done reasonably well for write transactions.
>
> Delete transactions, prior to dedup, were very light-weight, nearly free,
> so these are not managed.
>
> Be
2010/12/8 taemun :
> Dedup? Taking a long time to boot after hard reboot after lookup?
>
> I'll bet that it hard locked whilst deleting some files or a dataset that
> was dedup'd. After the delete is started, it spends *ages* cleaning up the
> DDT (the table containing a list of dedup'd blocks). If
Dedup? Taking a long time to boot after hard reboot after lookup?
I'll bet that it hard locked whilst deleting some files or a dataset that
was dedup'd. After the delete is started, it spends *ages* cleaning up the
DDT (the table containing a list of dedup'd blocks). If you hard lock in the
middle
slow boot: stuck at mounting zfs filesystems
Hi Frank,
you might face the problem of lots of snapshots of your filesystems.
For each snapshot a device is created during import of the pool. This can
easily lead to an extend startup time.
At my system it took about 15 minutes for 3500 snapshots.
2010
Hi Frank,
you might face the problem of lots of snapshots of your filesystems.
For each snapshot a device is created during import of the pool. This can
easily lead to an extend startup time.
At my system it took about 15 minutes for 3500 snapshots.
2010/12/8 Frank Van Damme
> Hello list,
>
>
Hello list,
I'm having trouble with a server holding a lot of data. After a few
months of uptime, it is currently rebooting from a lockup (reason
unknown so far) but it is taking hours to boot up again. The boot
process is stuck at the stage where it says:
mounting zfs filesystems (1/5)
the machin
