> On 3 Oct 2016, at 12:30 PM, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> Am Sun, 2 Oct 2016 15:30:41 -0400
> Allan Jude <allanj...@freebsd.org <mailto:allanj...@freebsd.org>> schrieb:
>> On 2016-10-02 15:25, O. Hartmann wrote:
>>> Running 12-CURRENT (FreeBSD 12.0-CURRENT #32 r306579: Sun Oct  2 09:34:50 
>>> CEST 2016
>>> ), I have a NanoBSD setup which creates an image for a router device.
>>> The problem I face is related to ZFS. The system has a system's SSD 
>>> (Samsung 850 Pro,
>>> 256GB) which has an UFS filesystem. Aditionally, I have also a backup and a 
>>> data HDD,
>>> both WD, one 3 TB WD RED Pro, on 4 TB WD RED (the backup device). Both the 
>>> sources for
>>> the NanoBSD and the object tree as well as the NANO_WORLDDIR are residing 
>>> on the 3 TB
>>> data drive. 
>>> The box itself has 8 GB RAM. When it comes to create the memory disk, which 
>>> is ~ 1,3
>>> GB in size, the NanoBSD script starts creating the memory disk and then 
>>> installing
>>> world into this memory disk. And this part is a kind of abyssal in terms of 
>>> the speed.
>>> The drive sounds like hell, the heads are moving rapidly. The copy speed is 
>>> incredibly
>>> slow compared to another box I usually use in the lab with UFS filesystem 
>>> only
>>> (different type of HDD).
>>> The whole stuff the nanbsd is installed from and to is on a separate ZFS 
>>> partition,
>>> but in the same pool as everything else. When I first setup the new 
>>> partitions, I
>>> switched on deduplication, but I quickly deactivated it, because it had a 
>>> tremendous
>>> impact on the working speed and memory consumption on that box. But 
>>> something seems
>>> not right since then - as I initially described, the copy/initialisation
>>> speed/bandwith is abyssal. Well, I also fear that I did something wrong 
>>> when I firt
>>> initialised the HDD - there is this 125bytes/4k block discussion and I do 
>>> not know
>>> how to check whether I'm affected to that or not (or even causing the 
>>> problems) and
>>> how to check whether DEDUPLICATION is definitely OFF (apart from the usual 
>>> stuff list
>>> features via "zfs get all").
>>> As an example: the nanbosd script takes ~ 1 minute to copy /boot/loader 
>>> from source to
>>> memory disk and the HDD makes sounds like hell and close to loosing the r/w 
>>> heads. On
>>> other boxes this task is done in a blink of an eye ...
>>> Thanks for your patience,
>>> Regards,
>>> oh
>> Turning deduplication off, only stops new blocks from being
>> deduplicated. Any data written while deduplication was on, are still
>> deduplicated. You would need to zfs send | zfs recv, or
>> backup/destroy/restore to get the data back to normal.
>> If the drive is making that much noise, have you considered that the
>> drive might be failing?
> Hello.
> Might there be any hint I can investigate on that ZFS partition showing me 
> that the
> particular partition is still doing deduplication? If I wouldn't know that I 
> switch
> dedup on and later off, I would blame the OS instead. So, for further 
> forensik analysis
> in the future, it would be nice to know how to look at it - if it is doable 
> via simple
> checking the features of the ZFS partition ...
> Thanks,
> oh 

not really an answer, but zpool has a nice command: history, it sometimes helps 
to find what and when
nfs commands where given.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to