3 ms·

One of the (many) things that struck me in the article was his dismissive remarks regarding copy on write within a filesystem. That seems like a fantastically u

One of the (many) things that struck me in the article was his dismissive remarks regarding copy on write within a filesystem. That seems like a fantastically useful feature for development, etc, where you are almost always building, then copying the artifacts into the deploy/test directory. Avoiding the disk IO in those situations seems like a pretty sound win to me in terms of giving a performance boost for free.

erichocean 10y ago
> was his dismissive remarks regarding copy on write within a filesystem ? ZFS is copy-on-write.
- Sanddancer 10y ago
  Yeah, I know ZFS is CoW, I use snapshots all the time when building jails/containers precisely for that reason. I was just struck by a few paragraphs from the article that really stuck out: > With APFS, if you copy a file within the same file system (or possibly the same container; more on this later), no data is actually duplicated. Instead, a constant amount of metadata is updated and the on-disk data is shared. Changes to either copy cause new space to be allocated (this is called "copy on write," or COW). btrfs also supports this and calls the feature "reflinks"—link by reference. > I haven't seen this offered in other file systems (btrfs excepted), and it clearly makes for a good demo, but it got me wondering about the use case. Copying files between devices (e.g. to a USB stick for sharing) still takes time proportional to the amount of data copied of course. Why would I want to copy a file locally? The common case I could think of is the layman's version control: "thesis," "thesis-backup," "thesis-old," "thesis-saving because I'm making edits while drunk." CoW is one of those features that is superficially questionable until you start noticing the bits and pieces of workflow it really makes faster and easier. Given the keynote was towards an audience of developers, I'm really surprised that there wasn't a demo showing how much faster deploys, etc are with such tech.
  - ysleepy 10y ago
    He is dismissive of file-level CoW. ZFS will also create new blocks if you cp a file, only dedup will remedy that. Also APFS only seems to do file-level CoW with a special syscall.
    - sho_hn 10y ago
      Note he was also not even aware of support for the same feature in btrfs until I pointed it out to him in an earlier HN discussion of his original blog post -- the version on Ars already pretends otherwise, without being marked as a fixup (though I am ready to blame this on Ars fully; his blog version includes an UPDATE tag and has better flow).
ahl 10y ago
COW is great. It has applicability around on-disk consisteny, and it makes snapshots much more coherent. It's also not without downsides such as fragmentation--though that's far far less important on SSDs than HDDs. Apple's fast file copy mechanism also uses COW. I would suggest that it's an instance of listening to what your customers say rather than providing them what they need. They say file copies are too slow, but what they really want is a way to track versions, retain old ones, etc. It would be cool if Apple built on their existing approach with regard to file versioning.

erichocean 10y ago

> was his dismissive remarks regarding copy on write within a filesystem ? ZFS is copy-on-write.

Sanddancer 10y ago
Yeah, I know ZFS is CoW, I use snapshots all the time when building jails/containers precisely for that reason. I was just struck by a few paragraphs from the article that really stuck out: > With APFS, if you copy a file within the same file system (or possibly the same container; more on this later), no data is actually duplicated. Instead, a constant amount of metadata is updated and the on-disk data is shared. Changes to either copy cause new space to be allocated (this is called "copy on write," or COW). btrfs also supports this and calls the feature "reflinks"—link by reference. > I haven't seen this offered in other file systems (btrfs excepted), and it clearly makes for a good demo, but it got me wondering about the use case. Copying files between devices (e.g. to a USB stick for sharing) still takes time proportional to the amount of data copied of course. Why would I want to copy a file locally? The common case I could think of is the layman's version control: "thesis," "thesis-backup," "thesis-old," "thesis-saving because I'm making edits while drunk." CoW is one of those features that is superficially questionable until you start noticing the bits and pieces of workflow it really makes faster and easier. Given the keynote was towards an audience of developers, I'm really surprised that there wasn't a demo showing how much faster deploys, etc are with such tech.
- ysleepy 10y ago
  He is dismissive of file-level CoW. ZFS will also create new blocks if you cp a file, only dedup will remedy that. Also APFS only seems to do file-level CoW with a special syscall.
  - sho_hn 10y ago
    Note he was also not even aware of support for the same feature in btrfs until I pointed it out to him in an earlier HN discussion of his original blog post -- the version on Ars already pretends otherwise, without being marked as a fixup (though I am ready to blame this on Ars fully; his blog version includes an UPDATE tag and has better flow).

ahl 10y ago

COW is great. It has applicability around on-disk consisteny, and it makes snapshots much more coherent. It's also not without downsides such as fragmentation--though that's far far less important on SSDs than HDDs. Apple's fast file copy mechanism also uses COW. I would suggest that it's an instance of listening to what your customers say rather than providing them what they need. They say file copies are too slow, but what they really want is a way to track versions, retain old ones, etc. It would be cool if Apple built on their existing approach with regard to file versioning.