Chris Murphy
Forum Replies Created
-
FusionIo PCIe flash is at 1.5GB/s per card. Not accounting for encoding, yes two in a raid0 will saturate one TB2 controller.
I haven’t tested Core Storage “fusion drive” in anything other than a consumer type workload. If a read results in a cache hit, then you get SSD read speeds. If it’s a cache miss, you’d get the raid speed. The write speed would always start out at SSD speed, but for video this would end quickly (within 4GB of writing) as Core Storage doesn’t aggressively migrate data off the SSD. This might be enough to moderate the slow ramp up Bob Zelin reported elsewhere… maybe. But just like raid0, if the SSD drive dies, kaboom to all data, not just what was on the SSD.
Bcache on Linux shows some promise, as it does have some knobs unlike Core Storage, but it’s a bit early to support in production. However, it’s mainly write through for sequential writes, so that will avoid the SSD. Whereas any random io caused by metadata writes (?) would hit the SSD and at least not reduce performance on the raid made of HDDs. Those random IOs hit the SSD in write back mode, get aggregated, and written sequentially to the HDD. But then, on linux there are other options like Infiniband which probably obviate the need for a local SSD cache anyway.
-
Additionally, I’d test the enclosures set to JBOD (if that’s possible), and test just one disk in each enclosure with software raid0. Then rebase with enclosures set to raid1, and then remake the software raid0 and test again. This gives some idea of the raid1 write hit and read gain. This would be workload independent, so the test method doesn’t matter as much.
The other test(s) would be changing the raid0 chunk size, which I think with Apple software raid defaults to 32KB which is almost certainly too small for video editing use case. I’d test the default, but also 512KB and then whatever the maximum offered is. However, for this test, it’s important to get test method to mimic the actual workload or the results will lead to the wrong conclusion.
And the repeat all the tests with eSATA!
When it comes to troubleshooting, a drag with USB is that most bridge chipsets don’t pass through SMART commands, and even with those that do OS X lacks the necessary driver support. Yes it’s only ~60% predictive of failures, but in cases of unexpected behavior, getting the full list of SMART attributes can sometimes be useful by suggesting sources of problems well before the simplistic pass/fail metric reaches the manufacturer defined threshold.
-
OK so I’ve played with this on 10.8.5 and I’m getting some fairly craptastic behavior.
Without sudo I can cp read or write a file from/to an NFS share without difficult, and with OK performance. However I can only read/copyfrom the Finder. I can’t write files from the Finder or from other apps.
When I try to Finder copy a file to an NFS share, I get a beachball. If I try to cancel, the copy dialog says “Stopping…” for 10+ minutes and doesn’t recover. Console reports:
kernel: nfs4_setclientid: client ID in use?
kernel: nfs4_setclientid failed, 10017
kernel: nfs mirror mount of 192.168.1.137:/chris on /Network/f20/chris failed (10017)And it repeats. I think this is a UID/GUID mapping problem, although I don’t know why the Finder is being such a misbehaving ill tempered dick about it when cp has no problem. Irritating.
-
If the server is NFSv4, rpcbind, lockd, and statd aren’t running. I haven’t tested it, but I figured by Mavericks NFSv4 would be the default, as it’s been around for 11 years already. If not, the command would be a variant of ‘sudo mount_nfs -o vers=4’ and since it uses TCP, rwsize defaults to 32KB. It might still be worth increasing the readahead value from the default of 16, and async if the proper precautions are taken and the risk is understood.
-
Do you mean RAID 1 among four disks creating two mirrored RAID sets; or do you mean a single RAID 10 set?
With USB I’d steer clear of software raid1. The 4Big may very well be software raid1 because it’s not listed, meaning it would be done through Apple Disk Utility. The difference is the mirroring with software will require two streams, consuming twice the bandwidth to the device. Whereas when implemented internal to the attached storage device (often hardware RAID but could still be software running within the box) it’s a single stream to the attached storage, and the device itself does the mirroring (again internally).
In theory with a 4 disk raid10 you could have up to 4x read performance (which depends on a less common layout, that also incurs a write performance hit), more typically it’s 2x the single disk read performance. With drives capable of 150MB/s transfer rates, for sure 4x hits the theoretical USB 3.0 bandwidth and busts the practical max. Even 2x, at 300MB/s is over the typical real world max transfer rate of 200MB/s of USB 3. So really you need to compute your present and future bandwidth requirement to know whether or not you need more than this. Just because the expected real world USB limit is less than Thunderbolt, doesn’t mean it’s disqualifying for your use case.
-
Yes that R4 article needs an editor. Even after some minutes of “WTF moments” I still end up not sorting out what it is saying. But it still lacks test method details.
I read that the R4 self read/write (duplicating a folder) was 100MB/s. And transfer from an R6 to R4 was 240MB/s. Yet the 2nd graphic shows the R4’s separate read/write performance as 170MB/s and 150MB/s. This makes exactly zero sense. How does it have 150MB/s write performance, and yet the R6 to R4 transfer was 240MB/s during which ostensibly the R4 is writing? :confused:
The R4 comes with 4 drives and RAID 5, which is how it was tested. The R4 data sheet says “up to” 800MB/s performance, and these numbers are well short of that. The data sheet says these are 7200RPM SATA drives. So we should see sequential reads in the vicinity of just under 3x the single drive read performance for full stripe reads (which may not be a real world test). A single Hitachi Ultrastar 7K4000 benches at 172MB/s average (maybe as low as 110MB/s for the inner zones), so yeah the article reports confusing performance. But then we don’t know their test method, or even Promise’s.
The test method is quite important, especially with RAID. If the test method doesn’t mimic actual workflow, the results can be skewed so badly as to be useless.
Worth a separate thread, if it doesn’t already exist, is what the range of video production workloads look like, and what’s typical or average (if there is such a thing). I suspect a very common workload is sequential read only, but then there’s also sequential read and write – but I don’t know if that looks like a folder duplication operation or something else. I’m also not familiar with the various file formats and how they contain video files, if they’re really one large file or if they’re smaller files in a container that looks like a file. Also relevant is how much metadata is being produced. Concurrent read/write seems like a worst case scenario for RAID, but maybe that’s the typical workload. There is a high performance penalty when there aren’t full stripe reads and especially for writes.
-
Well…at present the firmware is rather permissive. It’ll run any EFI application or OSLoader thrown at it.
Where it gets possibly concerning is if/when Apple applies what they’ve done with iOS to OS X. I don’t expect they’ll have opt out equivalents to Microsoft’s implementation of Secure Boot on x86_64. And as such it wouldn’t surprise me if Apple effectively presents its customers with Restricted Boot instead.
-
Apple has always done this since the beginning of time. What makes it more noticeable is when the cutoff is an x.0 release as is the case here. More often a new model comes out and gets a special build of 10.x.y and it will not boot less than the .y it came loaded with. I vaguely recall one or two times, maybe the Mac Pro faux-refresh, that we could go backward in OS version because, well, it really wasn’t all that different hardware wise.
So what’s going on is is that new hardware needs a new kernel and kexts to support things like the GPU, network, USB, and SATA controllers, and so on. Windows does this a bit differently in that an ancient base kernel can boot the system in a basic video mode, and then have recent video drivers added on. What would happen on say, linux, if you tried to use an old kernel and initramfs (equivalent to kext cache on OS X) on new hardware it was totally unprepared to run on, would be a kernel panic. Instead of doing something ugly, like kernel panicking that pretty Mac, Apple is probably inhibiting the very attempt at booting via the bootloader and firmware. The firmware likely knows what minimum boot.efi signature it will support. And if it doesn’t find that, it doesn’t offer it as an option.
So possibly you could grab the new boot.efi the machine wants, replacing the old boot.efi on the old system you need and see if the machine kernel panics (or worse, subsequently implodes an hour later for some reason – pretty unlikely it’s usually a fast, deterministic failure if it’s going to fail).
boot.efi is located in /System/Library/CoreServices.
-
LTFS uses XML spec 1.0 encoding, which itself can use either UTF-8 or UTF-16. OS X uses UTF-16 encoding for file names, with a few illegal characters. So ” is a legal character in LTFS, but it’s not legal on NTFS. So a decision has to be made whether to encode as is, and substitute on restore; or to either substitute encoding when backing up, or fail. And it seems HP has decided to go with the fail on the front end approach.
It’s interesting they chose to go this route with non-universally supported characters, while with case sensitivity naming conflicts they choose to rename the file (by adding an numer to the body of the file name). Anyway, it appears to be an implementation decision rather than an LTFS limitation.
-
A big part of why film is “best” is because it’s essentially self-describing by lacking an obscured encoding. The digital content involves multiple layers of encodings, and even if all of them were openly documented (which many aren’t) it’s that layering that turns unwinding it all in e.g. 20 years a really serious problem. But conversely film isn’t the best in that it isn’t original content, it’s the baked in totally rendered final output of a process. It’s a deliverable, even if it’s merely put into a freezer.
LTFS is supported on LTO6, they aren’t mutually exclusive. It’s well recognized that it only addresses part of the problem. There’s some interesting, not yet completed, work by SMPTE progressing on AXF. This attempt recognizes the problem isn’t just about media, let alone one kind of media. While LTFS was openly documented, and somewhat self-describing, it doesn’t really sufficiently solve most of the pressing archiving concerns. Hence why this work is being done by SMPTE rather than the storage industry (let alone a narrow slice of it).