Not to be confused with Rust Crates (which I mention because I was confused).
I think something went wrong here:
; For each [version, reads] pair, discard those with one value
multis (remove (fn <a href="/data/posts/332/k vs">k vs</a>
(= 1 (count (set (map :value vs)))))Is this bug in Crate, or Elasticsearch? I believe Crate bypasses Elasticsearch for some things and accesses shards directly, at least to perform query pushdown operations, but are they also handling the optimistic version control?
Red Sea is simple. I am commanding with divine authority. I don't argue. I am fucken Pope of Intel. Suck my cock and smile.
RedSea File System
The RedSea file system is a simple, 64-bit, file system which is similar to FAT32, but with absolute block addresses instead of clusters, fixed-sized 64-byte directory entries and no FAT table, just an allocation bitmap. A cluster is just one 512 byte sector. Files are stored in contiguous blocks and cannot grow in size.
#define CDIR_FILENAME_LEN 38 //Must include terminator zero
The following bit field shows valid 8-Bit ASCII filename characters.
U32 chars_bmp_filename[8]= {0x0000000, 0x03FF73FB, 0xEFFFFFFF, 0x2FFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF};
public class CDirEntry //64-byte fixed-size { U16 attr; //See RS_ATTR_DIR. I would like to change these. U8 name[CDIR_FILENAME_LEN]; //See chars_bmp_filename, FileNameChk I64 cluster; (blk) //One sector per cluster. I64 size; //In bytes CDate datetime; //See DateTime, Implementation of DateTime };
public class CRedSeaBoot //RedSea is type FAT32 in partition table to fool BIOS. { U8 jump_and_nop[3]; U8 signature,reserved[4]; //MBR_PT_REDSEA=0x88. Distinguish from real FAT32. I64 drv_offset; //For CD/DVD image copy. I64 sects; I64 root_cluster; (root_blk) I64 bitmap_sects; I64 unique_id; U8 code[462]; U16 signature2; //0xAA55 };
See ::/Kernel/BlkDev/FileSysRedSea.CPP and ::/Adam/Opt/Boot/DskISORedSea.CPP.
Files with names ending in .Z are compressed. See ::/Kernel/Compress.CPP.
To replace ISO9660, make hard-drive partition image of a measured size and copy onto a CD/DVD starting at about sector 20, with EL TORITO booting. 512-byte sectors will be placed on top of 2048-byte CD/DCD sectors, so there will be four blocks per CD/DVD sector.
RedSea file system has no bad block table and no redundant allocation table.
I have a general question about database reliability that perhaps someone could help me look into.
I love these Jepsen posts, and Kyle Kingsbury's work is amazing.
It all shows that distributed systems are really complicated and difficult to get right. These posts on the open source ones are really great. But how do you go about evaluating a proprietary one?
Let's say my company is looking for a columnar store. We look at the evaluation of Cassandra and think, "Nope."
But then someone says, "Hey! Let's go with Redshift!" How do you know that's any better?
We all know that DB makers claim certain things. Why would Amazon be better at this tricky subject than the people behind ElasticSearch?
My question is that I would really like to know what people think about this?
Is the decision that it's better to go with the unreliable demon that you know? Or is it better to pass the responsibility off to a company like Amazon, hope for the best, and lawyer up if unexpected things happen?