Mozilla Firefox and Mozilla Based Browsers.Google Chrome and Chromium Based Browsers.We have added support for the import of Favicon data as well as extraction of icons and associated Favicon images to the export folder for the following browsers: We have added new support in NetAnalysis® for the forensic analysis of the following browsers: We have also added support for some new artefacts. We have added support for six new browsers as well as making the necessary updates required to support the changes in the mainstream browsers. This release brings a number of new features and improvements. For an overview of the new features we are shipping inside NetAnalysis® v2.2 and HstEx® v4.2, please take a moment to review our release notes and change log: Afterwards you can add those bind mounts in /etc/fstab to perform them automatically during the system startup.We are pleased to announce the next major release for NetAnalysis® and HstEx® has just been published. And then you export that /nfs-share directory with "crossmnt" option, then mount that /nfs-share on the client and it will be able to see sda1 and sda2 mount contents within those mount1 and mount2 subdirectories. Then you create a directory /nfs-share and you mount those existing mounts as a bind mount: /nfs-share/mount1 and /nfs-share/mount2 (mount -bind /mount1 /nfs-share/mount1 and mount -bind /mount2 /nfs-share/mount2). Maybe that would be a workaround for your case?Įxample: In server you have /dev/sda1 mounted on /mount1 and /dev/sda2 mounted on /mount2. So I mount directly or as a bind mount some existing mounts from the server within the single NFS share, and with that "corssmnt" NFS export option the clients are be able to see those sub mounts within that NFS share. In my setup it works, I don't know what could cause this? Are you using the very same IP address or hostname to mount the NFS share at the client? I'm not using that scenario in my daily setup, but another thing I'm using all the times is "crossmnt" option at the server side. This is just an informative message to you guys because I tried to google this for some time and I didn't find any blogs or pages mentioning that user-space "copy_file_range" requirement in addition to the NFS v4.2.
UPDATE: throwaway6560192 mentioned in the comments that copy_file_range is implement into KDE Framework 5.88 onwards: I hope they'll implement this in the future.
This feature can still be easily disabled by using -reflink=never argument with cp command (in coreutils 9.0 cp command defaults to -reflink=auto: ).īut of course, other user-space file management/copying tools I'm using, like KDE's Dolphin and rsync don't support this. This is a significant performance gain in certain circumstances. So I compiled manually coreutils 9.0 on one of my Debian 11 NFS client machine and it works! Now if I copy something inside the NFS share (or from another NFS share to another, which are mounted from the same NFS server) the data gets copied on the NFS server locally and it's not round-tripping via the client anymore. Unfortunately, Ubuntu's and Debian's coreutils are still on v8.xx and they lack this functionality. And it seems that this feature has been recently added to coreutils' cp command (see: ) and it's available on coreutils v9.0 onwards. Then I was informed that it's not enough that shares are using NFSv4.2: the user-space tool that is used to copy the files needs to support "copy_file_range" syscall as well, to get the server-side copying to work properly. And the reason why I wanted NFSv4.2 was server-side copying feature, see: I think it's a killer feature, like reflinking over NFS (which, by the way works with BTRFS and XFS filesystems over NFS too!).īut even I had successfully set up the NFS v4.2, my copying tests (cp /mnt/nfs/src.file /mnt/nfs/dest.file) were indicating that the data is still round-tripping via the client. I have a Linux NFS server and clients (all are running Linux kernel 5.13 or higher) and I was able to set up network mounts by using the NFS version 4.2 (by using this guide here: ).
0 kommentar(er)
