i just googled for the btrfs syscall for hole punching (FALLOC_FL_PUNCH_HOLE) and then googled if zfs supports the same syscalls…
but if i have read the blog entry correct cp --reflink is not using that ioctl but more likely BTRFS_IOC_CLONE
Actually I changed it so that images are put into subvolumes so FALLOC_FL_PUNCH_HOLE support suffices. That is this issue https://github.com/zfsonlinux/zfs/issues/326 and though it is open it seems to be supported in 0.6.4 (see last comment).
I think the biggest problem would be that zfs does not have any implementation that works (as easy) like btrfs subvolumes…
zfs snapshots are always read only and you cant reference between different datasets. but…
that could be the same as copying a btrfs subvolume.
so you have to create a new dataset, write the full backup to it, snapshot the dataset and then clone that snapshot to a new one…
as clones relay on snapshots you can’t delete any snapshot that is cloned. if you do that multiple times for incremental backups you create chains of clones and snapshots that relay on each other and you can’t freeup that space
Played around a little bit with zfs snapshots and clones…
This isn’t as easy as i thought.
for a snapshot/clone you have to specify the pool/dataset and that has nothing to do with the actual filesystem hierarchy as with btrfs…
there has to be a new filed in the webinterface and config in which you can specify the actual zfs pool in wich the datasets are stored or you have to find out the pool from the mtab… dunno which one is easier…
Tried to install the beta on Freenas Jail.
I managed to get around the cc1plus: error: unrecognized command line option “-fstack-protector-strong”
error initially encoutered by install gcc49 pkg install gcc49
and then modifying the makefile (commented lines were the originals) #CC = gcc CC = gcc49 #CXX = g++ CXX = g++49 #CXXCPP = g++ -E CXXCPP = g++49 -E #ac_ct_CC = gcc #ac_ct_CXX = g++ ac_ct_CC = gcc49 ac_ct_CXX = g++49
This allowed the make to get much further, up until it hit BLKGETSIZE64 function in file_linux.cpp
Apparently this method does not exist in the freenas kernel. is there any way around this ?
I keep getting these messages while doing backups over internet using v2beta server and client the backup just hangs and never completes sometimes at 100% or lower
I upgraded the server to the Beta 2.0.0 and am getting an unending progress bar in the web interface. I tried uninstalling and installing fresh, but the problem still occurs. Here is the log :
It’s a private lab network. The server is just used for backup. The machines don’t even access the internet. 3 of 4 clients run XP. Is there any helpful information someone can offer?
Has anyone notice a speed difference between a client with 2.01 installed and 1.4.10? In a virtualized environment with all machine assigned the same amount of hardware resources I get 45Kbps for clients using 2.0.1 and 560Mbps for machines running the 1.4.10 client. Or was there a setting I missed?
Yeah, EOL does not simply mean that it is not receiving updates and that your only worries are from the internet. It also means that there will not be any bug fixes and that you are several years behind on features.
I know precisely what End Of Life means. I work in IT. I was running 1.4.12 on the server quite well. I decided to test the Beta as the new features are quite enticing. I found it is not working and posted to this forum as that is what this thread is for. If what you are saying is that the new version is specifically designed not to run on Server 2003, then I will either reinstall 1.4.12 or search for a different software for my purposes.
It means that few people will be interested in running it on Windows Server 2003. This being an Open Source project of course somebody could put in the work to support Windows Server 2003.
There is nothing wrong with staying on 1.4.12 either, if it works for you. After all you are staying with Windows Server 2003 because that still works.
To be quite frank, we are approaching a year that XP has been EOL, why would anyone target it? At this point, any project will continue building for it as long as it does not block anything else. As soon as it causes any difficultly in development, you drop all support. There is no sense in supporting a market that has completely faded.
Yeah, I haven’t done anything on purpose to remove the Windows XP support, but I haven’t tested it either (so it probably won’t work). This area is entirely complaint-driven.
If it does not load please use DependencyWalker to tell me which function it cannot load.
I haven’t done any major testing I just noticed that the lone xp client I was running the test on (rest are windows vista/7/8/10 and server 2008/2012) automatically updated to the 2.0.x beta from the server and then stopped connecting to the server (internet based) so no longer backing up