Fresco does not support disc cache for local photos which stored in disc - fresco

Fresco does not support disc cache for local images which stored in disc memory,but only support for images from network.
May this feature be fixed in the future.

Related

NAS systems recommendations for transferring large HFS+ Journaled data

I want to improve my backup system by using RAID technology accompanied by Cloud backup services.
I use several macOS computers, and would prefer the NAS solution over the DAS one.
The first step would be to backup all my existing data.
I currently store it in external HHD/SSD formatted in HFS+ Journaled;
1x HDD 4TB - almost full - Format: HFS+ Journaled.
1x SSD 4TB - almost full - Format: HFS+ Journaled.
1x SSD 1TB - almost full - Format: HFS+ Journaled.
My professional surroundings as well as reviews on the internet often recommend the brand Synology.
I was tempted to make the following investment according to my needs:
Synology DS1821+ (8 bays)
5x 8TB HHD (WD Red Plus WD80EFZX 8TB)
SHR-2 protection type (24TB of free space, 16TB allocated for protection)
IDriveĀ® Cloud backup service (provides DSM extension).
Problem:
I want to find the best way to efficiently and safely transfer all my current data (around 10 TB) from my external HDD/SSD disks (HFS+ Journaled fromats) to the future NAS volume.
I have the feeling that doing so via SMB or FTP will be way to long and uncertain.
So I thought that the most straight forward way would probably be to simply connect each external disks directly to the NAS (USB 3.1), and simply transfer portions of all data manually directly in DSM.
However, after extra investigations, I was surprised to learn the following:
Synology knowledge base says:
https://www.synology.com/enus/knowledgebase/DSM/help/DSM/AdminCenter/system_externaldevice_devicelist
Some models support HFS/HFS Plus with read-only.
Journal is not supported on HFS/HFS Plus.
You will need to install exFAT Access from Package Center to enable Synology NAS to support exFAT.
Make sure you have ejected the external disk before unplugging it.
Clearly states that no model supports journaling.
Product specs says:
https://www.synology.com/en-us/products/DS1821+#specs
Unless I am missing it, it does not inform much about the journaling matter or size limits.
About disabling journaling via the Disk utility app on macOS:
It feels like it is only possible via CLI these days (since BigSur).
I understand what disabling journaling implies, that it is probably not a big deal for temporary transferring all the data to the NAS, but I still would like to avoid such accommodations as much as possible (I've never done it, I don't know).
I looked for NAS alternatives that would support HFS+ Journaled formats but couldn't find any.
Are my concerns justified or am I overthinking this ?
Any pieces of advice from experienced NAS & macOS users would be much appreciated.

Imaging to Bigger SSD

I'm planning to image a laptop using Acronis or maybe Clonezilla from a 256GB 2.5" SSD to an NVMe 512GB.
The laptop is assigned to just one person but they have quite a few pieces of proprietary software and configurations, and they're encountering low disk spice and some crashing with some of their specialized apps.
My question: since it's a domain joined computer, is it still OK to image the old drive to the larger drive or should I un-join it from the domain before imaging and rejoin after restoring the image? And if so, when I re-join, would the account pickup the old profile folder from the restored image and be OK with all of their software configurations, etc?
If the proprietary software needs to check the domain for the right license, I'd recommend that you unjoin the domain and then image the disk. As soon as you re-image the new SSD with the old SSD, rejoin the domain. This should allow the software, config files, etc. to reactivate
Usually, domains save the data and configuration files in servers, so you should be good to go. But if the domain is not server-sided, I'd say you need to make the image and then flash it to the new SSD. Usually in the software, you can specify a configuration file to load. They are all on the disk, so even though this manual method takes longer, it is a great alternative.
But I'd also wait for another person to answer this question.

Difference between Image , VHD and Snapshot in Azure

I was able to take a snapshot of OS Disk of VM1 and create a disk out of it.
I have swapped with the VM1 OS Disk for learning purpose. I'm aware we can also create a new VM out of this snapshot as well.
There is another way to create a blob storage with VHD file and create a managed OS disk by selecting OS type as Windows/linux and then swap with VM1 OS Disk.
There is also a way to create an image by selecting same VHD file and create a completely new VM out of it.
I want to understand in detail the difference between Image, VHD and Snapshot.
Is Image = VHD bundled with OS.
Does VHD contain OS?
Is Snapshot a VDH at a point of time?
Does Snapshot contains OS as well?
Thank you very much in advance.
Well, if the existing issue does not answer solve the question. I would show you something that I understand about the three things via answer the four questions.
Is Image = VHD bundled with OS.
I think it's not. The image can contain the OS disk and the data disk. So you can treat it as a thing that contains multiple VHD files. And the OS disk is the must-have for the image.
Does VHD contain OS?
No, VHD is a format of a file that contains a virtual hard disk used by Microsoft Windows Virtual PC. The hard disk can be the OS disk or the data disk, but not both.
Is Snapshot a VHD at a point of time?
Yes, the snapshot is a full, read-only copy of a virtual hard drive (VHD).
Does Snapshot contains OS as well?
Perhaps. If the snapshot is a copy of the OS disk, of course, it contains the OS disk. But if the snapshot is a copy of the data disk, then it doesn't. You can tread snapshot the same as the VHD file in a special moment.

How Do I Reduce Size of UWP App (Can I Compress HD Images?)

My UWP app for Windows 10, which is in development at the moment and has about 400 - 500 HD images, takes up a whopping 1.7 GB of hard drive space. File Explorer claims that the images take up about 1.68 GB while the code is the other 0.02 GB...
When all is said and done, the app needs to have a couple thousand HD images. Clearly this will be unsustainable as the size of the app will be nearly 10 GB, or possibly even larger.
Is there a way to compress these images within the app?
This is unrelated to this Stack Overflow question. I am not using Xamarin. Also I tested downloading a release build from the Store to confirm--and it does in fact say it is 1.7 GB in size.
The images used in the application are actually application resources.
When the application is packaged, this part of the resource will not be specially processed. You can only compress the image before packaging, or consider extracting the image resource to allow the user to Download and import image resources after installing the application.
Just like some online games, after downloading the game body, they will download additional data packets the first time they run. This part of the resource is not hosted by the store, but is deposited by the developer.

Google chrome takes 1.1 gb of memory to download and load a large image (24000x12000) of size 17.2 mb

How does google chrome browser internally work while downloading and processing images?
When one tries to open this image then google chrome task manager shows 1.1 GB of memory footprint(do make sure you use disabled cache while replication)
After the image is downloaded and loaded then the memory is released and it drops to 77 MB of memory footprint
I couldn't figure out any reason for such high memory consumption. Neither what chrome internally does that consumes such huge memory.
I'm looking for any relevant answer or blog which can help me understand the internal architecture or design which guides chrome to behave such a way.
JPEG is a compressed image storage format. For displaying the image, an application has to uncompress it in memory. A reasonable expectation is 4 bytes per pixel (one byte for each color channel), so your image takes 24000*12000*4 bytes = 1.07 GB.

Resources