SplitFS: Reducing Software Overhead in File Systems for Persistent - - PowerPoint PPT Presentation

▶
splitfs reducing software overhead in file systems for
SMART_READER_LITE
LIVE PREVIEW

SplitFS: Reducing Software Overhead in File Systems for Persistent - - PowerPoint PPT Presentation

Aug 17, 2022 364 likes •1.47k views

SplitFS: Reducing Software Overhead in File Systems for Persistent Memory Rohan Kadekodi, Se Kwon Lee, Sanidhya Kashyap*, Taesoo Kim, Aasheesh Kolli, Vijay Chidambaram * on the job market 1 Persistent Memory (PM) Non-volatile Fast

slide-1
SLIDE 1

SplitFS: Reducing Software Overhead in File Systems for Persistent Memory

Rohan Kadekodi, Se Kwon Lee, Sanidhya Kashyap*, Taesoo Kim, Aasheesh Kolli, Vijay Chidambaram

* on the job market

  • 1
slide-2
SLIDE 2

Persistent Memory (PM)

Non-volatile Fast

  • 2
slide-3
SLIDE 3

PM file systems

  • 3
slide-4
SLIDE 4

PM file system

PM file systems

Application File 1 PM File 2 File n

  • 3
slide-5
SLIDE 5

PM file system

PM file systems

Application File 1 PM File 2 File n read(), write(),

  • pen(), close()

POSIX API

  • 3
slide-6
SLIDE 6

PM file system

PM file systems

Application File 1 PM File 2 File n read(), write(),

  • pen(), close()

POSIX API

ext4-DAX PMFS NOVA Strata

  • 3
slide-7
SLIDE 7

ext4-DAX

700

  • 4
slide-8
SLIDE 8

ext4-DAX

700

  • 4

Modification of the ext4 file system for Persistent Memory Works with modern Linux kernels Under active development by the ext4 community Only PM file system that is widely used

slide-9
SLIDE 9

Software Overhead in File Systems

700

  • Append 4KB data to a file

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

Time (ns)

  • 5
slide-10
SLIDE 10

Software Overhead in File Systems

700

Time (ns)

  • 5

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

700

  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns
slide-11
SLIDE 11

Software Overhead in File Systems

700

Time (ns)

  • 5
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

700 9002 (12x)

slide-12
SLIDE 12

Software Overhead in File Systems

700

Time (ns)

  • 5
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

700 9002 (12x) software

  • verhead
slide-13
SLIDE 13

Software Overhead in File Systems

700

Time (ns)

  • 5
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

4150 (5x) 3021 (3x) 700 2450 (2.5x) 9002 (12x)

slide-14
SLIDE 14

Software Overhead in File Systems

700

Time (ns)

  • 5
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

4150 (5x) 3021 (3x) 700 2450 (2.5x) 9002 (12x)

File systems suffer from high software overhead!

slide-15
SLIDE 15

Software Overhead in File Systems

700

Time (ns)

  • 5
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

2000 4000 6000 8000 10000 device Strata NOVA PMFS ext4-DAX

4150 (5x) 3021 (3x) 700 2450 (2.5x) 9002 (12x)

File systems suffer from high software overhead! ext4-DAX, although widely used, suffers from highest software overhead and provides weak guarantees

slide-16
SLIDE 16
  • 6

Goals

slide-17
SLIDE 17
  • Low software overhead
  • 6

Goals

slide-18
SLIDE 18
  • Low software overhead
  • Strong consistency guarantees
  • 6

Goals

slide-19
SLIDE 19
  • Low software overhead
  • Strong consistency guarantees
  • Leverage the maturity and active

development of ext4-DAX

  • 6

Goals

slide-20
SLIDE 20

SplitFS

POSIX file system aimed at reducing software overhead for PM

  • 7
  • 7
slide-21
SLIDE 21

SplitFS

POSIX file system aimed at reducing software overhead for PM SplitFS serves data operations from user space and metadata

  • perations using the ext4-DAX kernel file system
  • 7
  • 7
slide-22
SLIDE 22

SplitFS

POSIX file system aimed at reducing software overhead for PM SplitFS serves data operations from user space and metadata

  • perations using the ext4-DAX kernel file system

Provides strong guarantees such as atomic and synchronous data operations

  • 7
  • 7
slide-23
SLIDE 23

SplitFS

POSIX file system aimed at reducing software overhead for PM SplitFS serves data operations from user space and metadata

  • perations using the ext4-DAX kernel file system

Reduces software overhead by up to 17x compared to ext4-DAX https://github.com/utsaslab/splitfs Provides strong guarantees such as atomic and synchronous data operations

  • 7
  • 7

Improves application throughput by up to 2x compared to NOVA

slide-24
SLIDE 24

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Consistency guarantees
  • Evaluation
  • 8
slide-25
SLIDE 25

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Consistency guarantees
  • Evaluation
  • 9
slide-26
SLIDE 26

Target usage scenario

  • 10
slide-27
SLIDE 27

Target usage scenario

  • 10

SplitFS is targeted at POSIX applications which use read() / write() system calls in order to access their data on Persistent Memory.

slide-28
SLIDE 28

Target usage scenario

  • 10

SplitFS is targeted at POSIX applications which use read() / write() system calls in order to access their data on Persistent Memory. SplitFS does not optimize for the case when multiple processes concurrently access the same file

slide-29
SLIDE 29

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Consistency guarantees
  • Evaluation
  • 11
slide-30
SLIDE 30

High-level Design

  • 12
slide-31
SLIDE 31

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX
  • 12
slide-32
SLIDE 32

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX
  • 12

Data in kernel Metadata in kernel Data in user Metadata in user

slide-33
SLIDE 33

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX

ext4-DAX, PMFS [EuroSys 14], NOVA [FAST 16]

  • 12

Data in kernel Metadata in kernel Data in user Metadata in user

slide-34
SLIDE 34

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX

ext4-DAX, PMFS [EuroSys 14], NOVA [FAST 16] Low performance

  • 12

Data in kernel Metadata in kernel Data in user Metadata in user

slide-35
SLIDE 35

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX

ext4-DAX, PMFS [EuroSys 14], NOVA [FAST 16] Strata [SOSP 17] Low performance

  • 12

Data in kernel Metadata in kernel Data in user Metadata in user

slide-36
SLIDE 36

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX

ext4-DAX, PMFS [EuroSys 14], NOVA [FAST 16] Strata [SOSP 17] Low performance High complexity

  • 12

Data in kernel Metadata in kernel Data in user Metadata in user

slide-37
SLIDE 37

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX

ext4-DAX, PMFS [EuroSys 14], NOVA [FAST 16] Strata [SOSP 17] Low performance High complexity

  • 12

Data in kernel Metadata in kernel Data in user Metadata in user Aerie [EuroSys 14] High complexity Data in user Metadata in user Allocations in kernel Low performance

slide-38
SLIDE 38

High-level Design

SplitFS lies both in user space as well as in the kernel.

  • Data operations are served from user space
  • Metadata operations are served from ext4-DAX

ext4-DAX, PMFS [EuroSys 14], NOVA [FAST 16] Strata [SOSP 17] Low performance High complexity SplitFS Low complexity High performance Data in user Metadata in kernel

  • 12

Data in kernel Metadata in kernel Data in user Metadata in user Aerie [EuroSys 14] High complexity Data in user Metadata in user Allocations in kernel Low performance

slide-39
SLIDE 39

High-level Design

  • 13

High performance Low complexity

slide-40
SLIDE 40

High-level Design

  • 13

Accelerate data operations from user space

  • Data operations are common and simple

High performance Low complexity

slide-41
SLIDE 41

High-level Design

  • 13

Accelerate data operations from user space

  • Data operations are common and simple

Use ext4-DAX for metadata operations

  • Metadata operations are rare and complex
  • POSIX has many complex corner-cases

High performance Low complexity

slide-42
SLIDE 42

High-level Design

user kernel Application File 1 File 2 File 3 PM

  • 14

U-Split K-Split (ext4-DAX)

slide-43
SLIDE 43

High-level Design

user kernel Application File 1 File 2 File 3 PM read() write()

  • 14

U-Split K-Split (ext4-DAX)

slide-44
SLIDE 44

High-level Design

creat() delete() user kernel Application File 1 File 2 File 3 PM read() write()

  • 14

U-Split K-Split (ext4-DAX)

slide-45
SLIDE 45

High-level Design

creat() delete() user kernel Application File 1 File 2 File 3 PM read() write()

  • 14

Log U-Split K-Split (ext4-DAX)

slide-46
SLIDE 46

High-level Design

creat() delete() user kernel Application File 1 File 2 File 3 PM read() write()

  • 14

Log U-Split

SplitFS accelerates common case data operations while leveraging the maturity of ext4-DAX for metadata operations

K-Split (ext4-DAX)

slide-47
SLIDE 47

High-level Design

creat() delete() user kernel Application File 1 File 2 File 3 PM read() write()

  • 14

Log U-Split

SplitFS accelerates common case data operations while leveraging the maturity of ext4-DAX for metadata operations

K-Split (ext4-DAX)

SplitFS uses logging and out of place updates for providing atomic and synchronous operations

slide-48
SLIDE 48

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Handling file reads and updates
  • Handling file appends
  • Consistency guarantees
  • Evaluation
  • 15
slide-49
SLIDE 49

K-Split (ext4-DAX) U-Split Application File PM User Kernel

Handling reads and updates

  • 16
slide-50
SLIDE 50

read / update K-Split (ext4-DAX) U-Split Application File PM User Kernel

Handling reads and updates

  • 16
slide-51
SLIDE 51

read / update K-Split (ext4-DAX) U-Split Application File PM mmap perform mmap User Kernel

Handling reads and updates

  • 16
slide-52
SLIDE 52

read / update K-Split (ext4-DAX) U-Split Application File PM DAX-mmaps mmap perform mmap User Kernel

Handling reads and updates

  • 16
slide-53
SLIDE 53

read / update K-Split (ext4-DAX) U-Split Application File PM DAX-mmaps User Kernel

Handling reads and updates

  • 16
slide-54
SLIDE 54

read / update K-Split (ext4-DAX) U-Split Application File PM DAX-mmaps User Kernel

In the common case, file reads and updates do not pass through the kernel

Handling reads and updates

  • 16
slide-55
SLIDE 55

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Handling file reads and updates
  • Handling file appends
  • Consistency guarantees
  • Evaluation
  • 17
slide-56
SLIDE 56

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel

slide-57
SLIDE 57

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application Start

slide-58
SLIDE 58

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start

slide-59
SLIDE 59

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap

slide-60
SLIDE 60

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) abc store

slide-61
SLIDE 61

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) abc read (foo) load

slide-62
SLIDE 62

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) abc read (foo) fsync (foo)

slide-63
SLIDE 63

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) abc read (foo) fsync (foo)

relink()

slide-64
SLIDE 64

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) abc read (foo) fsync (foo) foo staging ext4-journal transaction

relink()

slide-65
SLIDE 65

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) read (foo) fsync (foo) foo staging ext4-journal transaction abc

relink()

slide-66
SLIDE 66

foo size = 10 foo inode Persistent Memory

Handling appends

  • 18

user kernel Application staging file size = 100 staging file inode Start staging file mmap append (foo,“abc”) read (foo) fsync (foo) foo staging ext4-journal transaction abc

In the common case, file appends do not pass through the kernel

relink()

slide-67
SLIDE 67

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Consistency guarantees
  • Evaluation
  • 19
slide-68
SLIDE 68

Consistency Guarantees

Mode Metadata Atomicity Synchronous Operations Data Atomicity File System POSIX ext4-DAX, SplitFS-POSIX Sync PMFS, SplitFS-Sync Strict NOVA, Strata, SplitFS-Strict

  • 20
slide-69
SLIDE 69

Consistency Guarantees

Mode Metadata Atomicity Synchronous Operations Data Atomicity File System POSIX ext4-DAX, SplitFS-POSIX Sync PMFS, SplitFS-Sync Strict NOVA, Strata, SplitFS-Strict

  • 20
slide-70
SLIDE 70

Consistency Guarantees

Mode Metadata Atomicity Synchronous Operations Data Atomicity File System POSIX ext4-DAX, SplitFS-POSIX Sync PMFS, SplitFS-Sync Strict NOVA, Strata, SplitFS-Strict

  • 20
slide-71
SLIDE 71

Consistency Guarantees

Mode Metadata Atomicity Synchronous Operations Data Atomicity File System POSIX ext4-DAX, SplitFS-POSIX Sync PMFS, SplitFS-Sync Strict NOVA, Strata, SplitFS-Strict

  • 20
slide-72
SLIDE 72

Consistency Guarantees

Mode Metadata Atomicity Synchronous Operations Data Atomicity File System POSIX ext4-DAX, SplitFS-POSIX Sync PMFS, SplitFS-Sync Strict NOVA, Strata, SplitFS-Strict

Optimized logging is used in order to provide stronger guarantees in sync and strict modes

  • 20
slide-73
SLIDE 73

Optimized logging

  • 21
slide-74
SLIDE 74

SplitFS employs a per-application log in sync and strict mode, which logs every logical operation

Optimized logging

  • 21
slide-75
SLIDE 75

SplitFS employs a per-application log in sync and strict mode, which logs every logical operation In the common case

  • Each log entry fits in one cache line
  • Persisted using a single non-temporal store and sfence instruction

Optimized logging

  • 21
slide-76
SLIDE 76

Flexible SplitFS

K-Split (ext4-DAX) App 1 File 1 PM App 2 App 3 File 2 File 3 File 4 User Kernel

  • 22
slide-77
SLIDE 77

Flexible SplitFS

K-Split (ext4-DAX) App 1 File 1 PM App 2 App 3 U-Split- POSIX U-Split- sync U-Split- strict File 2 File 3 File 4 User Kernel

  • 22
slide-78
SLIDE 78

Flexible SplitFS

K-Split (ext4-DAX) App 1 File 1 PM App 2 App 3 U-Split- POSIX U-Split- sync U-Split- strict File 2 File 3 File 4 Data Data Data Meta Meta Meta User Kernel

  • 22
slide-79
SLIDE 79
  • 23

Visibility

slide-80
SLIDE 80
  • 23

Visibility

When are updates from one application visible to another?

slide-81
SLIDE 81
  • 23
  • All metadata operations are immediately visible

to all other processes

Visibility

When are updates from one application visible to another?

slide-82
SLIDE 82
  • 23
  • All metadata operations are immediately visible

to all other processes

Visibility

  • Writes are visible to all other processes on

subsequent fsync() When are updates from one application visible to another?

slide-83
SLIDE 83
  • 23
  • All metadata operations are immediately visible

to all other processes

Visibility

  • Writes are visible to all other processes on

subsequent fsync()

  • Memory mapped files have the same visibility

guarantees as that of ext4-DAX When are updates from one application visible to another?

slide-84
SLIDE 84

SplitFS Techniques

Technique Benefit

  • 24
slide-85
SLIDE 85

SplitFS Techniques

Technique Benefit

SplitFS Architecture Low-overhead data operations, Correct metadata operations

  • 24
slide-86
SLIDE 86

SplitFS Techniques

Technique Benefit

SplitFS Architecture Low-overhead data operations, Correct metadata operations Staging + Relink Optimized appends, No data copy

  • 24
slide-87
SLIDE 87

SplitFS Techniques

Technique Benefit

SplitFS Architecture Low-overhead data operations, Correct metadata operations Staging + Relink Optimized appends, No data copy Optimized Logging + out-of-place writes Stronger guarantees

  • 24
slide-88
SLIDE 88

Outline

  • Target usage scenario
  • High-level design
  • Handling data operations
  • Consistency guarantees
  • Evaluation
  • 25
slide-89
SLIDE 89

Evaluation

  • 26
slide-90
SLIDE 90

Evaluation

Setup:

  • 2-socket 96-core machine with 32 MB LLC
  • 768 GB Intel Optane DC PMM, 378 GB DRAM
  • 26
slide-91
SLIDE 91

Evaluation

Setup:

  • 2-socket 96-core machine with 32 MB LLC
  • 768 GB Intel Optane DC PMM, 378 GB DRAM

File systems compared:

  • ext4-DAX, PMFS, NOVA, Strata
  • 26
slide-92
SLIDE 92

Evaluation

Setup:

  • 2-socket 96-core machine with 32 MB LLC
  • 768 GB Intel Optane DC PMM, 378 GB DRAM
  • 26

File systems compared:

  • ext4-DAX, PMFS, NOVA, Strata
slide-93
SLIDE 93

Does SplitFS reduce software overhead compared to other file systems? How does SplitFS perform on metadata intensive workloads? How does SplitFS perform on data intensive workloads?

  • 27
slide-94
SLIDE 94

Does SplitFS reduce software overhead compared to other file systems? How does SplitFS perform on metadata intensive workloads? How does SplitFS perform on data intensive workloads?

  • 27
  • < 15% overhead for metadata intensive workloads
slide-95
SLIDE 95
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

Software Overhead of SplitFS

2000 4000 6000 8000 10000 device SplitFS-strict Strata NOVA PMFS ext4-DAX

4150 (5x) 3021 (3x) 9002 (12x) 700 2450 (2.5x)

Time (ns)

  • 28
slide-96
SLIDE 96
  • Append 4KB data to a file
  • Time taken to copy user data to PM: ~700 ns

Software Overhead of SplitFS

Time (ns)

  • 28

2000 4000 6000 8000 10000 device SplitFS-strict Strata NOVA PMFS ext4-DAX

1251 (0.8x) 4150 (5x) 3021 (3x) 700 2450 (2.5x) 9002 (12x)

slide-97
SLIDE 97

Workloads

YCSB on LevelDB Seq reads Redis Tar Git Rsync Microbenchmarks Data intensive Metadata intensive TPCC on SQLite Rand reads Seq writes Rand writes Appends

  • 29
slide-98
SLIDE 98

Workloads

YCSB on LevelDB Seq reads Redis Tar Git Rsync Microbenchmarks Data intensive Metadata intensive TPCC on SQLite Rand reads Seq writes Rand writes Appends

  • 29
slide-99
SLIDE 99

YCSB on LevelDB

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 5M operations. Key size = 16 bytes. Value size = 1K

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F NOVA SplitFS-Strict

Normalized throughput

  • 30
slide-100
SLIDE 100

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F NOVA SplitFS-Strict

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes 13.39 kops/s 32.24 kops/s 139.94 kops/s 174.85 kops/s 191.54 kops/s 13.59 kops/s 17.75 kops/s 66.54 kops/s

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 5M operations. Key size = 16 bytes. Value size = 1K

YCSB on LevelDB

Normalized throughput

  • 31
slide-101
SLIDE 101

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 5M operations. Key size = 16 bytes. Value size = 1K

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F NOVA SplitFS-Strict

13.39 kops/s 32.24 kops/s 139.94 kops/s 174.85 kops/s 191.54 kops/s 13.59 kops/s 17.75 kops/s 66.54 kops/s

YCSB on LevelDB

Normalized throughput

  • 32
slide-102
SLIDE 102

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 5M operations. Key size = 16 bytes. Value size = 1K Read-heavy workloads optimized because of converting reads to loads

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F NOVA SplitFS-Strict

13.39 kops/s 32.24 kops/s 139.94 kops/s 174.85 kops/s 191.54 kops/s 13.59 kops/s 17.75 kops/s 66.54 kops/s

YCSB on LevelDB

Normalized throughput

  • 32
slide-103
SLIDE 103

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 5M operations. Key size = 16 bytes. Value size = 1K

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F NOVA SplitFS-Strict

13.39 kops/s 32.24 kops/s 139.94 kops/s 174.85 kops/s 191.54 kops/s 13.59 kops/s 17.75 kops/s 66.54 kops/s

YCSB on LevelDB

Normalized throughput

  • 33
slide-104
SLIDE 104

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 5M operations. Key size = 16 bytes. Value size = 1K Write-heavy workloads optimized because of staging and relink

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F NOVA SplitFS-Strict

13.39 kops/s 32.24 kops/s 139.94 kops/s 174.85 kops/s 191.54 kops/s 13.59 kops/s 17.75 kops/s 66.54 kops/s

YCSB on LevelDB

Normalized throughput

  • 33
slide-105
SLIDE 105

SplitFS

  • 34
slide-106
SLIDE 106

SplitFS

SplitFS introduces a new architecture for building PM file systems that… reduces software overhead, provides strong guarantees, and leverages the widely-used ext4-DAX

  • 34
slide-107
SLIDE 107

SplitFS

SplitFS introduces a new architecture for building PM file systems that… reduces software overhead, provides strong guarantees, and leverages the widely-used ext4-DAX https://github.com/utsaslab/splitfs

  • 34
slide-108
SLIDE 108

Backup Slides

  • 35
slide-109
SLIDE 109

Load A - 100% writes Run A - 50% reads, 50% writes Run B - 95% reads, 5% writes Run C - 100% reads Run D - 95% reads (latest), 5% writes Load E - 100% writes Run E - 95% range queries, 5% writes Run F - 50% reads, 50% read-modify-writes

Yahoo! Cloud Serving Benchmark - Industry standard macro-benchmark Insert 5M keys. Run 1M operations. Key size = 16 bytes. Value size = 1K

YCSB on LevelDB

Normalized throughput

  • 36

0.5 1 1.5 2 2.5 Load A Run A Run B Run C Run D Load E Run E Run F Strata SplitFS-Strict