If you can't keep the editors trained on this, then making separate ExFAT/NTFS copies for the Windows people is one solution. Using ExFAT for shuttle drives is the simplest solution and if all downstream FCPX editors understand they shouldn't import from those drives, it's OK. In a mixed Windows/Mac environment which uses physical media, this won't work. If using a SAN or LAN it doesn't make any difference. In the less frequent case a non-Mac user needs the data, then it can be copied to ExFAT or NTFS. In an all-Mac or mostly-Mac environment using physical media, you can just decree that all drives including shuttle drives are HFS+.
DISKWARRIOR 5 APFS MAC
You can use Paragon NTFS on Mac or Paragon HFS on Windows, but the user base of people using that for heavy-duty FCPX work is relatively small. While ExFAT is tested and supported on macOS, it is probably not the highest priority in Apple's test matrix for FCPX. But when doing critical database operations, a conservative approach is wise. The editor figures out the ExFAT-formatted T5 is really nice and fast so they just put the library on that and keep using it. With increasing use of ProRes material and USB-C SSD drives, this seems more common. What if the ingest workflow involves Finder tags or maybe later use of FindrCat to export FCPX keywords to Finder tags? How well does ExFAT support that and Spotlight indexing of those? I don't know but that would concern me.įCPX is not doing only large sequential reads from media files but heavy-duty random IOs to the SQLite database, and sometimes even the library gets placed on the ExFAT "shuttle" drive. ExFAT is not journaled so it's less resilient to a system crash. Then you end up with active FCPX media on ExFAT which generally works but is not as safe or as well tested. Yes this is fundamentally a training issue but I've seen it happen many times. An editor will be handed a nice fast Samsung T5 or similar drive, be told "this is today's material", and instead of copying that to their RAID they will import straight from the ExFAT-formatted T5. In a collaborative FCPX environment the problem with ExFAT on "shuttle" or offloading drives is these often get mixed up as media drives. Otherwise it can mean handoff of physical media. LAN/SAN transfer is OK if everyone is on 10-gig ethernet. We shoot a lot of multi-camera 4k ProRes material so it's just too large for easy internet file transfer. In fact the camera cards are usually ExFAT. I also recommend if you do need to share to PCs.įor data offloading ExFAT is OK.
DISKWARRIOR 5 APFS MOVIE
I do use ExFAT for thumb drives for movie distribution. There is no benefit to using ExFAT and you lose all of the benefits of APFS like write on copy, fast encryption, etc…. Even MS is moving away from ExFAT and now defaults to NTFS which has some of the benefits of write protections, larger block sizing, and more. I also recommend if you do need to share to PCs. Yes I know for some folks, they never experience issues, but Why? Just my 2c There is no benefit to using ExFAT and you lose all of the benefits of APFS like write on copy, fast encryption, etc… while increasing the likely hood of slowdowns and corruption. If Apple can't do it…? HFS+ despite being long in tooth performs fine and maintains backwards compatibility, so for me, there are not benefits that make it necessary.Īs for ExFAT and other formatting options, Why? The only reason to use non-native drive formats is if you need to share a drive with a Windows computer. Time Machine still doesn't work and is HFS+ only. There are indeed other issues as reported around the web.Į/7/is-apfs-fully-supported-yet/ĪPFS has improved for spinning disks, remember when you couldn't even use APFS for hdds or Fusion Drives. I think that I disagree with the last paragraph, but then I think that the pluses of APFS is not that great on spinning drives, so I do not recommend APFS on hdds at this time.
blog/2/analysis-apf.m_source=xlr8yourmac
Recently found this article by Bombich Carbon Copy Cloner makers on performance hits when using APFS on spinning hard drives.
0 kommentar(er)
