cokernel_hacker

Yep, numeronyms.

http://en.wikipedia.org/wiki/Numeronym

The address of the domain is now 41.77.118.2 which is managed by a service of French origin.

Concurrent Programming on Windows by Joe Duffy http://www.amazon.com/exec/obidos/ASIN/032143482X/bluebyteso...

It is not, it contains pieces of various BSD libc derivatives:

http://codingrelic.geekhold.com/2008/11/six-million-dollar-l...

Do you consider xnu to be general purpose? OS X/iOS have been tickless for a long, long time.

Can you please elaborate on this inherent design flaw? My understanding of NTOS DPCs is that they are quite similar to Linux tasklets/bottom-half interrupt handlers.

The most common implementation technique that I know of is to include a small constant number (~4) bytes of the actual name next to the hash.

Variable length keys are difficult to implement efficiently. The alternative is not doing file name lookups by key query which would damage performance in unpatholgical cases.

Sadly, this article gets some stuff about btrfs wrong. Allow me to clarify:

* First off, btrfs does not use "hash tables". Instead, it uses hashes to create keys that index into B-Trees. The problem is that hash collisions are not handled with an efficient approach. btrfs is forced to do a lot of work to deal with these collisions.

* ZFS uses two distinct data structures to represent the contents of a directory: the so-called "micro-ZAP" and the so-called "fat-ZAP"

micro-ZAPs are for small directories. This is OK as the number of collisions is limited by the relatively small size of the micro-ZAP.

fat-ZAPs are like on-disk extensible hash-tables.

They both use CRC64, I think that fat-ZAPs might have a problem.

As a professional storage engineer, your comment strikes my heart with horror. A reproducible bug that causes a crash/hang/loss of data in your file system in patently unacceptable.

We labor to design a system that stores data safely to a stable medium. This is done while acknowledging that we are not perfect and cannot get everything right. HOWEVER, when we know that we have done something wrong and it can gravely affect a user, we do not ship. Ever. Period.

"Software has bugs" is the lamest excuse to ship something with bugs. Do you think that pacemaker firmware leaves the factory floor with known bugs? I doubt it.

I like write-anywhere/COW filesystems.

Unfortunately the open source ones kinda blow due to interesting performance penalties (I'm looking at you, btrfs back ref management) or crazy memory usage/non-extent based systems/read-modify-write induced mania (I'm looking at you, ZFS block tree)

My apologies but what sciurus might be addressing and what I am talking about are addressing two very different things.

There is a bug in ext4, https://lkml.org/lkml/2012/10/25/521

Note that this is dated after the "Wed, 24 Oct 2012 17:31:29 -0400" post and talks about changing code related to a truncated journal.

My post does not say anything about the likelihood of the dataloss due to such bugs, I mention what happens in every design in a WAL journaling system.

Talking about the impact of a particular ext bug is up to the people who post on the LKML. To be honest, I don't really care how severe the bug is, I care about why there are bugs and journal truncation is a source of them.

I would rather not have byzantine relations between fragments of code make up the policy of my file system's metadata resiliency thank-you-very-much. I would rather prefer that stale journal replays be no-ops, even at the expense of making journal replay slower.

This is symptomatic with one of my two big problems with journalling oriented file-systems.

My problems with journalling are two fold:

1) They are very slow:

1a) You have a nice big sequential write into the journal, which is OK.

1b) A flush track cache to make sure it is actually in the journal. This can sync whatever has accumulated in the track cache which might not just be journal data.

1c) The actual overwrites that spew data randomly over the drive.

1d) Writes to update the journal header/terminate the transaction.

1e) A final flush track cache which will sync who-knows-what onto the platters/flash.

2) Replay behavior of the journal log is _very_ fragile code. You need to handle lots of terrible cases, the most awful of which is to ensure that you don't play older transaction on top of newer transactions. You might say "hey, that shouldn't happen!" but it happens. It happens because the code is not trivial to write and detecting these bad cases aren't trivial. Even if you do get the code write, you are still screwed. Why? Because if your drive does not support the flush track cache mechanism you are in for a world of pain. You can have a journal and journal header that is ancient if it just stuck in some cache...

The ext* family of filesystems do not appear to have natural resiliency to this sort of problem. Instead, it appears to be a coordinated, concerted effort between various parts of the journaling code.

The good ideas taken from plan9 aren't isolated to it and could have been fostered outside of it, perhaps speeding up adoption of those ideas.

> That's a strange way to describe research and experimentation (though not strictly incorrect).

Many of the modern OS research papers that I have read take an existing solution and mess with it. As an example, many file system papers take ext[34] or btrfs and do something to them (if we want to debate this statement, we can). I see this with replacement algorithms, packet schedulers, etc. Much experimentation happens but it is usually in the context of Linux or FreeBSD or some other popular existing solution these days.

There are papers that buck this more conventional approach like barrelfish and singularity and exokernels and L4 etc. etc. etc.

I do not think they are the status quo and I am/was not saying that plan9 is a bad thing, let me be clear on that.

>Plan 9 predates all of today's mainstream operating systems.

This is said with enough certainty without being true that I am allergic to it. All? Plan 9 started in the late 80's [1] OS X/iOS is a mach derivative which is circa 1985. The NT OS/2 project which begat modern Windows was started in 1988. BSD? All descendants of BSD which first released in 1977. Rob Pike complains about BSD's "cat -v" in the early 80's.

Maybe you are using "predate" with a different connotation but I don't know which. At the very best* it co-existed with the others.

[1] http://plan9.bell-labs.com/sys/doc/9.html

My general take from observing their culture is dogmatic vs pragmatic. plan9 and go are dogmatic, they exist because the status quo is bad and something must be done.

This is not to say their ideas are bad! Some of them are great but many of the great ones are brought into the mainstream thru unix (procfs, utf-8) and C (unnamed substructures) :)

I just wished they focused on making the mainstream better instead of this more indirect route...

And "just" a 32x increase in flash size.

Mini-filters are FS level as are VFS solutions. How do you tell a thing that sits at the VFS level about multiple devices? You could probably do it, nothing storage engineers solve is unsolvable :)

It certainly seems unnatural.

Most of those appliance solutions (and probably Fusion Drive for that matter) implement their mojo at the block level and provide block device interfaces. This is to aid their seamlessness, it makes them a lot more straightforward to implement and it makes them a lot more flexible. I would have trouble believing it would be simpler to implement it at a mini-filter/VFS level.

StorSimple, 3PAR, etc. all appear to be appliances. What I am trying to get as is subtle so I will try to be a little bit more explicit.

StorSimple can dominate the appliance it is made out of to provide its services. Fusion Drive cannot dominate the owner's machine.

Tiered storage has been done before, this is true. However, they are dedicated systems. If "Fusion Drive" is at the OS level, that means it shares resources with the rest of the system which presents more/different challenges.

Not even sorta similar, "ReadyBoost" is a cache

"Fusion Drive" provides the union of space.

They are in the same vein of "hide the slowness of rotational media" but that is a pretty huge vein.

This is not a hybrid drive, it is two drives as evidenced by the picture of the iMac that Phil Schiller showed.

This is more akin to "tiered storage" which has existed before, just not in the consumer space which prevents more/different challenges.

You are comparing "Momentus" a hybrid drive with "Fusion Drive" a tiered storage solution. Fusion Drive gives you a giant, huge SSD drive compared to Momentus' on-drive flash. We are talking about orders of magnitude in difference in flash size.

There are several reasons why OS integration could yield better performance. Notably, an understanding of what happens at boot time. While the machine is running, stuff useful for boot may not be used again. However, the OS can signal to the tiered storage "hey, we are shutting down. prepare the SSD so it will be fast for boot!".

The scenarios are endless. We could talk about hibernation, etc.

You are not correct, it is _not_ a cache but instead something that provides the union of storage between two drives. Remember, the examples have stuff _only_ on the SSD.

Instead, this appears to be an implementation of so-called "tiered storage". This is novel in that is the first time such an approach has been applied to consumer grade solutions. Usually, one might find tiered storage as part of an extremely expensive solution that EMC might give you as part of an elaborate storage system.

vector::emplace_back ameliorates by allowing new elements to be constructed in-place [1]

[1] http://en.cppreference.com/w/cpp/container/vector/emplace_ba...

Transactional filesystems have been implemented at considerable expense. To be clear, I mention transactions at a high enough level to encompass deleting a subdirectory (most reasonably implemented filesystems have support for tiny transaction that ensure that metadata is available on disk in a consistent fashion).

When I say considerable expense, I mean _very_ considerable expense. I know of no efficient implementation and only one practical implementation: TxF. TxF is not very fast either, it requires double the writes and, on top of that, is not easy to use. Microsoft is considering deprecating TxF due to the cost of continuing it's maintenance at the expense of other features [1]

I think a more reasonable model for what you want is filesystem snapshots. This is a feature that can be implemented with relatively high performance and without causing terribly large amounts of complication (needing to transact file descriptors, etc.)

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/hh80...

YAFFS is a log-structured filesystem, just like F2FS. Log-structuring gives you a data organization protocol. This protocol gives you an implicit crash-recovery story, there is no need for additional journaling on top of it.

Journalling is used when some blocks on the disk are scheduled to be overwritten. Instead, the blocks are written in a separate location (the so-called journal). At a later point in time, the data blocks get overwritten. Once the data is safely on the disk (via Forced Unit Access (FUA) or a flush track cache-type operation) we can then truncate the journal.

Log-structured systems do not do this. Instead, the achieve crash safety via never overwriting data; they always write elsewhere (into something called 'the log'). Eventually, too much of this log is filled with garbage, stale data. This is when 'cleaning' occurs. However, cleaning is expensive and slow. You must read a large amount of data, figure out what is alive/dead, and then write it all out.

F2FS's contribution to FS design seems to be handling this cleaning operation in a more graceful manner.

They are all cryptographers and at least three of them have deep academic backgrounds...

Guido Bertoni: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/b/...

Joan Daemen: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/d/...

Gilles Van Assche: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/a/...

Joan Daemen has a PhD, his thesis was "Cipher and Hash Function Design. Strategies based on linear and differential cryptanalysis"

Gilles Van Assche was a PhD student at the University of Brussels studying "classical and quantum information theory" (http://gva.noekeon.org/)

Clang is a C/C++ compiler, it has nothing to do with linking! The lld [1] project aims to be a linker, it is still relatively young.

[1] http://lld.llvm.org/