SSD and non-SSD Suitability

I've got a somewhat broad question on the suitability of nilfs for various workloads and different backing storage devices. From what I understand from the documentation available, the idea is to always write sequentially, and thus avoid slow random writes on old/naive SSDs. Hence I have a few questions.

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway. Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

Many thanks.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I haven't got any particular quantitative data by my own, so I'll write somewhat subjective opinion.

Quoted 3 lines

I've got a somewhat broad question on the suitability of nilfs for various workloads and different backing storage devices. From what I understand from the documentation available, the idea is to always write sequentially, and thus avoid slow random writes on old/naive SSDs. Hence I have a few questions.

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway. Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

In terms of writing performance, it may not have additional benefits I guess. However, it still have benefits with regard to continuous snapshots.

Quoted 1 line

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

I think it may have benefits, for nilfs will write sequentially whatever data is located before writing it. But still some tweaks might be required to speed up compared with ordinary filsystem like ext3.

Quoted 1 line

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

The data is scattered if you modified the file again and again, but it'll be almost sequential at the creation time. So it will affect much if files are modified frequently.

Quoted 1 line

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

For now, my understanding, nilfs garbage collector moves the live (in use) blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Quoted 1 line

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

You can find public benchmark results at the following links. However those are a bit old and current results may differ.

http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1
http://www.linux-mag.com/cache/7345/1.html

Quoted 2 lines · Jiro SEKIBA

I haven't got any particular quantitative data by my own, so I'll write somewhat subjective opinion.

Thanks, I appreciate it. :)

Quoted 10 lines

Quoted 9 lines

I've got a somewhat broad question on the suitability of nilfs for various workloads and different backing storage devices. From what I understand from the documentation available, the idea is to always write sequentially, and thus avoid slow random writes on old/naive SSDs. Hence I have a few questions.

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway. Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

Quoted 2 lines

In terms of writing performance, it may not have additional benefits I guess. However, it still have benefits with regard to continuous snapshots.

How does this compare with btrfs snapshots? When you say continuous, what are the breakpoints between them?

Quoted 7 lines

Quoted 3 lines

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

I think it may have benefits, for nilfs will write sequentially whatever data is located before writing it. But still some tweaks might be required to speed up compared with ordinary filsystem like ext3.

Can you quantify what those tweaks may be, and when they might become available/implemented?

Quoted 7 lines

Quoted 3 lines

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

The data is scattered if you modified the file again and again, but it'll be almost sequential at the creation time. So it will affect much if files are modified frequently.

Right. So bad for certain tasks, such as databases.

Quoted 10 lines

Quoted 4 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

For now, my understanding, nilfs garbage collector moves the live (in use) blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Since this moves files, it sounds like this could be a major issue for flash media since it unnecessarily creates additional writes. Can this be suppressed?

Quoted 7 lines

Quoted 6 lines

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

Quoted 5 lines

You can find public benchmark results at the following links. However those are a bit old and current results may differ.

http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1
http://www.linux-mag.com/cache/7345/1.html

Thanks.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

At Fri, 28 May 2010 10:50:31 +0100,

Quoted 19 lines · Gordan Bobic

Quoted 3 lines · Jiro SEKIBA

I haven't got any particular quantitative data by my own, so I'll write somewhat subjective opinion.

Thanks, I appreciate it. :)

Quoted 10 lines

Quoted 10 lines

I've got a somewhat broad question on the suitability of nilfs for various workloads and different backing storage devices. From what I understand from the documentation available, the idea is to always write sequentially, and thus avoid slow random writes on old/naive SSDs. Hence I have a few questions.

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway. Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

Quoted 6 lines

Quoted 3 lines

In terms of writing performance, it may not have additional benefits I guess. However, it still have benefits with regard to continuous snapshots.

How does this compare with btrfs snapshots? When you say continuous, what are the breakpoints between them?

I don't know well about btrfs, but I guess you can create a "snapshot" of current filesystem. You can not create yesterday's snapshot. While nilfs can do the trick :) to create snapshot of yesterday's filessytem state.

Nilfs creates snapshots from checkpoints. Checkpoints are created automatically almost each time filesystem changed (it depends how frequently system changed). If you leave the checkpoints as its are, garbage collector will collect those as free diskspace. Until then, the checkpoints are reachable by making it as snapshot.

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

I think it may have benefits, for nilfs will write sequentially whatever data is located before writing it. But still some tweaks might be required to speed up compared with ordinary filsystem like ext3.

Can you quantify what those tweaks may be, and when they might become available/implemented?

I might choose the wrong word, but what I meant is more hack is required to improve write performance. Not just configuration matters :(.

Quoted 10 lines

Quoted 8 lines

Quoted 4 lines

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

The data is scattered if you modified the file again and again, but it'll be almost sequential at the creation time. So it will affect much if files are modified frequently.

Right. So bad for certain tasks, such as databases.

Indeed. maybe /var type of directories too.

Quoted 11 lines

Quoted 11 lines

Quoted 5 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

For now, my understanding, nilfs garbage collector moves the live (in use) blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Quoted 4 lines

Since this moves files, it sounds like this could be a major issue for flash media since it unnecessarily creates additional writes. Can this be suppressed?

You can simply kill the nilfs_clearnerd after you mount the nilfs partition.

This case, of course, any garbage is reclaimed and finally end up with disk full, even size of files don't occupy the storage size.

I don't have data for now, but it made about twice better write performance compared with "with garbage collector".

thanks,

regards,

Quoted 24 lines

Quoted 7 lines

Quoted 7 lines

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

Quoted 6 lines

You can find public benchmark results at the following links. However those are a bit old and current results may differ.

http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1
http://www.linux-mag.com/cache/7345/1.html

Thanks.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 10 lines

Quoted 10 lines

Quoted 8 lines

Quoted 2 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

For now, my understanding, nilfs garbage collector moves the live (in use) blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Since this moves files, it sounds like this could be a major issue for flash media since it unnecessarily creates additional writes. Can this be suppressed?

Quoted 2 lines

You can simply kill the nilfs_clearnerd after you mount the nilfs partition.

If you use the latest nilfs_utils, killing nilfs_cleanerd is no longer necessary. You can use mount -o nogc. This will not start nilfs_cleanerd. Another possibility is to let nilfs_cleanerd start and tweak min_free_segments and max_free_segments so that cleanerd will only do cleaning if necessary.

Quoted 20 lines · David Arendt

Quoted 20 lines

Quoted 13 lines

Quoted 5 lines

Quoted 5 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

Quoted 8 lines

For now, my understanding, nilfs garbage collector moves the live (in use)
blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is
nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Quoted 4 lines

Since this moves files, it sounds like this could be a major issue for flash media since it unnecessarily creates additional writes. Can this be suppressed?

You can simply kill the nilfs_clearnerd after you mount the nilfs partition.

Quoted 5 lines

If you use the latest nilfs_utils, killing nilfs_cleanerd is no longer necessary. You can use mount -o nogc. This will not start nilfs_cleanerd. Another possibility is to let nilfs_cleanerd start and tweak min_free_segments and max_free_segments so that cleanerd will only do cleaning if necessary.

What about making the gc run only if the disk has been idle for, say, 20ms, unless min_free_segments is reached?

Gordan

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

I think it may have benefits, for nilfs will write sequentially whatever data is located before writing it. But still some tweaks might be required to speed up compared with ordinary filsystem like ext3.

Can you quantify what those tweaks may be, and when they might become available/implemented?

I might choose the wrong word, but what I meant is more hack is required to improve write performance. Not just configuration matters :(.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

The data is scattered if you modified the file again and again, but it'll be almost sequential at the creation time. So it will affect much if files are modified frequently.

Right. So bad for certain tasks, such as databases.

Indeed. maybe /var type of directories too.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

For now, my understanding, nilfs garbage collector moves the live (in use) blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Quoted 1 line

Since this moves files, it sounds like this could be a major issue for flash media since it unnecessarily creates additional writes. Can this be suppressed?

You can simply kill the nilfs_clearnerd after you mount the nilfs partition. This case, of course, any garbage is reclaimed and finally end up with disk full, even size of files don't occupy the storage size.

I don't have data for now, but it made about twice better write performance compared with "with garbage collector".

Quoted 9 lines · Jiro SEKIBA

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

I think it may have benefits, for nilfs will write sequentially whatever data is located before writing it. But still some tweaks might be required to speed up compared with ordinary filsystem like ext3.

Can you quantify what those tweaks may be, and when they might become available/implemented?

Quoted 2 lines

I might choose the wrong word, but what I meant is more hack is required to improve write performance. Not just configuration matters :(.

I understand what you meant. I just wanted to know when those hacks may be implemented and be available for those of us interested in using nilfs to optimize write-heavy workloads.

Quoted 9 lines

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

The data is scattered if you modified the file again and again, but it'll be almost sequential at the creation time. So it will affect much if files are modified frequently.

Right. So bad for certain tasks, such as databases.

Indeed. maybe /var type of directories too.

Interesting. So nilfs' suitability for write heavy loads is actually quite limited on mechanical disks, as it isn't suitable for append-heavy situations such as databases and logging, but for use-cases that are write+delete heavy such as mail servers or other spool type loads it should still be advantageous.

Quoted 13 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

Quoted 8 lines

Quoted 5 lines

For now, my understanding, nilfs garbage collector moves the live (in use) blocks to the end of logs, so holes are not created (it is correct?). However, it leads another issue that garbage collector process, which is nilfs_cleanerd, will consume the I/O. This is major I/O performance bottle neck current implementation.

Since this moves files, it sounds like this could be a major issue for flash media since it unnecessarily creates additional writes. Can this be suppressed?

Quoted 6 lines

You can simply kill the nilfs_clearnerd after you mount the nilfs partition. This case, of course, any garbage is reclaimed and finally end up with disk full, even size of files don't occupy the storage size.

I don't have data for now, but it made about twice better write performance compared with "with garbage collector".

What about enabling garbage collection, but disabling degragmentation? De-allocating space that isn't used any more is a necessary evil, but defragmentation is rather pointless in a lot of cases (e.g. SSDs) and counter-productive in others (mechanical disks under heavy load). Also, what about making the garbage collector "lazy", so that it runs either just-in time to overwrite discarded data (worst case scenario) or runs when the disks are idle (e.g. at ionice -c3, and even that only when there have been no disk transactions for, some selectable number of ms)?

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I've got a somewhat broad question on the suitability of nilfs for various workloads and different backing storage devices. From what I understand from the documentation available, the idea is to always write sequentially, and thus avoid slow random writes on old/naive SSDs. Hence I have a few questions.

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

Many thanks.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 1 line

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Could you explain that, as far as i know modern SSD's have 8 independant channels to do read and writes, which is why they are having that big read and write speed and can in theory therefore support 8 threads doing reads and writes. Each channel say using blocks of 4KB, so it's 64KB in total.

Quoted 6 lines

Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

Basically the main difference between SSD's and traditional disks is that SSD's have a faster latency, have more than 1 channel and write small blocks of 4KB, whereas 64KB read/writes are already real small for a traditional disk.

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

Quoted 3 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

Isn't ext2 a bit old?

Of course i understand you skip ext4 as that obviously still has to get bugfixed.

Quoted 2 lines · Vincent Diepeveen

Quoted 1 line

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Could you explain that, as far as i know modern SSD's have 8 independant channels to do read and writes, which is why they are having that big read and write speed and can in theory therefore support 8 threads doing reads and writes. Each channel say using blocks of 4KB, so it's 64KB in total.

I'm talking about something else. I'm talking about the fact that you can turn logical random writes into physical sequential writes by re-mapping logical blocks to sequential physical blocks.

Old, naive flash without clever firmware was always good at sequential writes but bad at random writes. Since fragmentation on flash doesn't matter since there is no seek time, modern SSDs use such re-mapping to prolong flash life, reduce the need for erasing blocks and improve random write performance by linearizing it.

This is completely independent of the fact that you might be able to write to the flash chips in a more parallel fashion because the disk ASIC has the ability to use more of them simultaneously.

Quoted 6 lines

Quoted 6 lines

Does nilfs demonstrably provide additional benefits on such modern SSDs with sensible firmware?

2) Mechanical disks suffer from slow random writes (or any random operation for that matter), too. Do the benefits of nilfs show in random write performance on mechanical disks?

3) How does this affect real-world read performance if nilfs is used on a mechanical disk? How much additional file fragmentation in absolute terms does nilfs cause?

Quoted 1 line

Basically the main difference between SSD's and traditional disks is that SSD's have a faster latency, have more than 1 channel and write small blocks of 4KB, whereas 64KB read/writes are already real small for a traditional disk.

Which begs the question why the traditional disks only support multi-sector transfers of up to 16 sectors, but that's a different question.

Quoted 1 line

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

The only actual benefit is decreased latency.

Quoted 5 lines

Quoted 4 lines

4) As the data gets expired, and snapshots get deleted, this will inevitably lead to fragmentation, which will de-linearize writes as they have to go into whatever holes are available in the data. How does this affect nilfs write performance?

5) How does the specific writing amount measure against other file systems (I'm specifically interested in comparisons vs. ext2). What I mean by specific writing amount is for writing, say, 100,000 random sized files, how many write operations and MBs (or sectors) of writes are required for the exact same operation being performed on nilfs and ext2 (e.g. as measured by vmstat -d).

Isn't ext2 a bit old?

So? The point is that it has no journal, which means fewer writes. fsck on SSDs only takes a few minutes at most.

Quoted 1 line

Of course i understand you skip ext4 as that obviously still has to get bugfixed.

It seems to be deemed stable enough for several distros, and will be the default in RHEL6 in a few months' time, so that's less of a concern.

I am more interested in metrics for how much writing is required relative to the amount of data being transferred. For example, if I am restoring a full running system (call it 5GB) from a tar ball onto nilfs2, ext2, ext3, btrfs, etc., I am interested in how many blocks worth of writes actually hit the disk, and to a lesser extent how many of those end up being merged together (since merged operations, in theory, can cause less wear on an SSD because bigger blocks can be handle more efficiently if erasing is required.

Gordan

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Could you explain that, as far as i know modern SSD's have 8 independant channels to do read and writes, which is why they are having that big read and write speed and can in theory therefore support 8 threads doing reads and writes. Each channel say using blocks of 4KB, so it's 64KB in total.

I'm talking about something else. I'm talking about the fact that you can turn logical random writes into physical sequential writes by re-mapping logical blocks to sequential physical blocks.

That's doing 2 steps back in history isn't it?

The big speedup that SSD's deliver for average usage is ESPECIALLY because of the faster random access to the hardware.

if you have some petabytes of storage, i guess the bigger bandwidth that SSD's deliver is not relevant, as the limitation is the network bandwidth anyway, so some raid5 with extra spare will deliver more than sufficient bandwidth.

Quoted 3 lines

Quoted 1 line

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

The only actual benefit is decreased latency.

Which is mighty important; so the ONLY interesting type of filesystem for a SSD is a filesystem that is optimized for read and write latency rather than bandwidth IMHO.

Especially read latency i consider most important.

Quoted 4 lines

Quoted 1 line

Of course i understand you skip ext4 as that obviously still has to get bugfixed.

It seems to be deemed stable enough for several distros, and will be the default in RHEL6 in a few months' time, so that's less of a concern.

I ran into severe problems with ext4 and i just used it at 1 harddrive, same experiences with other linux users.

Note i used ubuntu.

Stuff like RHEL is more expensive a copy than i have at my bank account.

Quoted 1 line

I am more interested in metrics for how much writing is required relative to the amount of data being transferred. For example, if I am restoring a full running system (call it 5GB) from a tar ball onto nilfs2, ext2, ext3, btrfs, etc., I am interested in how many blocks worth of writes actually hit the disk, and to a lesser extent how many of those end up being merged together (since merged operations, in theory, can cause less wear on an SSD because bigger blocks can be handle more efficiently if erasing is required.

The most efficient blocksize for SSD's is 8 channels of 4KB blocks.

Quoted 5 lines · Vincent Diepeveen

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Could you explain that, as far as i know modern SSD's have 8 independant channels to do read and writes, which is why they are having that big read and write speed and can in theory therefore support 8 threads doing reads and writes. Each channel say using blocks of 4KB, so it's 64KB in total.

I'm talking about something else. I'm talking about the fact that you can turn logical random writes into physical sequential writes by re-mapping logical blocks to sequential physical blocks.

That's doing 2 steps back in history isn't it?

Sorry, I don't see what you mean. Can you elaborate?

Quoted 1 line

The big speedup that SSD's deliver for average usage is ESPECIALLY because of the faster random access to the hardware.

Sure - on reads. Writes are a different beast. Look at some reviews of SSDs of various types and generations. Until relatively recently, random write performance (and to a large extent, any write performance) on them has been very poor. Cheap flash media (e.g. USB sticks) still suffers from this.

Don't confuse fast random reads with fast random writes.

Quoted 2 lines

if you have some petabytes of storage, i guess the bigger bandwidth that SSD's deliver is not relevant, as the limitation is the network bandwidth anyway, so some raid5 with extra spare will deliver more than sufficient bandwidth.

RAID3/4/5/6 is inherently unsuitable for fast random writes because if a write-read-write cycle required to update the parity.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

The only actual benefit is decreased latency.

Which is mighty important; so the ONLY interesting type of filesystem for a SSD is a filesystem that is optimized for read and write latency rather than bandwidth IMHO.

Indeed, I agree (up to a point). Random IOPS has long been the defining measure of disk performance for a reason.

Quoted 1 line

Especially read latency i consider most important.

Depends on your application. Remember that reads can be sped up by caching.

I look after a number of systems running applications that are write-bound because the vast majority of reads can be satisfied from page cache, but writes are unavoidable because transactions have to be committed to persistent storage.

You cannot limit your performance assessment to the use-case of an average desktop user running Firefox, Thunderbird and OpenOffice 99% of the time. Those are not the users that file systems advances of the past 30 years are aimed at.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

Of course i understand you skip ext4 as that obviously still has to get bugfixed.

It seems to be deemed stable enough for several distros, and will be the default in RHEL6 in a few months' time, so that's less of a concern.

I ran into severe problems with ext4 and i just used it at 1 harddrive, same experiences with other linux users.

How recently have you tried it? RHEL6b has only been out for a month.

Quoted 1 line

Note i used ubuntu.

I guess that explains some of your desktop-centric views.

Quoted 1 line

Stuff like RHEL is more expensive a copy than i have at my bank account.

RHEL6b is a public beta, freely downloadable.

CentOS is a community recompile of RHEL, 100% binary compatible, just with different artwork/logos. Freely available. As is Scientific Linux (a very similar project to CentOS, also a free recompile of RHEL). If you haven't found them, you can't have looked very hard.

Quoted 2 lines

Quoted 1 line

I am more interested in metrics for how much writing is required relative to the amount of data being transferred. For example, if I am restoring a full running system (call it 5GB) from a tar ball onto nilfs2, ext2, ext3, btrfs, etc., I am interested in how many blocks worth of writes actually hit the disk, and to a lesser extent how many of those end up being merged together (since merged operations, in theory, can cause less wear on an SSD because bigger blocks can be handle more efficiently if erasing is required.

The most efficient blocksize for SSD's is 8 channels of 4KB blocks.

I'm not going to bite and get involved in debating the correctness of this (somewhat limited) view. I'll just point out that it bears very little relevant to the paragraph that it appears to be responding to.

Gordan

Quoted 4 lines

Quoted 1 line

The big speedup that SSD's deliver for average usage is ESPECIALLY because of the faster random access to the hardware.

Sure - on reads. Writes are a different beast. Look at some reviews of SSDs of various types and generations. Until relatively recently, random write performance (and to a large extent, any write performance) on them has been very poor. Cheap flash media (e.g. USB sticks) still suffers from this.

You wouldn't want to optimize a file system for hardware of the past is it?

Before a file system is any mature, the hardware that is the standard today will be very common.

Quoted 5 lines

Quoted 2 lines

if you have some petabytes of storage, i guess the bigger bandwidth that SSD's deliver is not relevant, as the limitation is the network bandwidth anyway, so some raid5 with extra spare will deliver more than sufficient bandwidth.

RAID3/4/5/6 is inherently unsuitable for fast random writes because if a write-read-write cycle required to update the parity.

Nearly all major supercomputers use raid5 with extra spare as well as most database servers.

Stock exchange is more into raid10 type clustering,
but those few harddrives that the stock exchange uses, is that relevant?

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

The only actual benefit is decreased latency.

Which is mighty important; so the ONLY interesting type of filesystem for a SSD is a filesystem that is optimized for read and write latency rather than bandwidth IMHO.

Indeed, I agree (up to a point). Random IOPS has long been the defining measure of disk performance for a reason.

I'm always very careful saying a benchmark is holy.

Quoted 3 lines

Quoted 1 line

Especially read latency i consider most important.

Depends on your application. Remember that reads can be sped up by caching.

Even relative simple caching is very difficult to improve, with random reads.

The random read speed is of overwhelming influence.

Quoted 1 line

I look after a number of systems running applications that are write-bound because the vast majority of reads can be satisfied from page cache, but writes are unavoidable because transactions have to be committed to persistent storage.

You're assuming the working set size fits in caching, which is a very interesting assumption.

Quoted 1 line

You cannot limit your performance assessment to the use-case of an average desktop user running Firefox, Thunderbird and OpenOffice 99% of the time. Those are not the users that file systems advances of the past 30 years are aimed at.

Actually manufacturers design cpu's based upon a good analysis of the spec and linpack benchmark.

That's how it works in reality.

If i would generate them the 'stupid manner', which is how about all software works, then it would be harddrive latency bound. Of course there is no budget for SSD's for the generation of it, i explained you my financial status already.

So in contradiction to Ken Thompson i have to be clever.

So already a year or 10 ago with some others we figured out a manner of generating that's a lot faster and which is not i/o bound but CPU bound and also the CPU instructions needed have been reduced up roughly factor 60.

Yet you know what?

Number of reads is bigger than the number of writes. So it's a few dozen petabyte writes in total and a bit more reads than that. Probably i'll figure out for this run how to turn off caching, as i cache myself in the entire RAM already.

Of course i use a relative small amount of RAM whenever possible, because the latency is the CPU always in all calculations and the bandwidth to the RAM. Now when using a small amount of RAM, when that is possible, say a couple of hundreds of MB, the latency within that is always faster than when using the entire gigabytes of RAM that the box has.

Even simple old file systems already can get to the full bandwidth of any hardware, both read and write, as this proces is not random, but has been bandwidth optimized for both i/o as well as CPU.

When the final set has been generated, what will happen with it, is some sort of supercompression to it. Then it'll fit on SSD hardware easily.

Then it will only be used for reads during searches. So all what matters then is the random read latency.

This is kind of true for most databases which do not fit in the RAM.

Number of reads is so overwhelming bigger, that basically with SSD's you care most for random read speed of course.

Now you have a point that the random write speed is important in many applications; however it can be a few factors worse than random read speed, as long as it isn't phenomenal weaker.

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

I am more interested in metrics for how much writing is required relative to the amount of data being transferred. For example, if I am restoring a full running system (call it 5GB) from a tar ball onto nilfs2, ext2, ext3, btrfs, etc., I am interested in how many blocks worth of writes actually hit the disk, and to a lesser extent how many of those end up being merged together (since merged operations, in theory, can cause less wear on an SSD because bigger blocks can be handle more efficiently if erasing is required.

The most efficient blocksize for SSD's is 8 channels of 4KB blocks.

I'm not going to bite and get involved in debating the correctness of this (somewhat limited) view. I'll just point out that it bears very little relevant to the paragraph that it appears to be responding to.

Don't act arrogant.

To say it in a manner guys with 100 IQ points below me understand;
If you're doing random writes using the 8 independant channels of 4KB you'll hit the full bandwidth of the SSD basically.

Quoted 7 lines · Vincent Diepeveen

Quoted 4 lines

Quoted 1 line

The big speedup that SSD's deliver for average usage is ESPECIALLY because of the faster random access to the hardware.

Sure - on reads. Writes are a different beast. Look at some reviews of SSDs of various types and generations. Until relatively recently, random write performance (and to a large extent, any write performance) on them has been very poor. Cheap flash media (e.g. USB sticks) still suffers from this.

You wouldn't want to optimize a file system for hardware of the past is it?

Before a file system is any mature, the hardware that is the standard today will be very common.

There are a few problems with that line of reasoning.

1) Legacy support is important. If it wasn't, file systems would be strictly in the realm of fixed disk manufacturers, and we would all be using object based storage. This hasn't happened, nor is it likely to in the next decade.

2) We cannot optimize for hardware of the future, because this hardware may never arrive.

3) "Hardware of the past" is still very much in full production, and isn't going away any time soon.

The only sane option is to optimize for what is prevalent right now.

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

if you have some petabytes of storage, i guess the bigger bandwidth that SSD's deliver is not relevant, as the limitation is the network bandwidth anyway, so some raid5 with extra spare will deliver more than sufficient bandwidth.

Quoted 3 lines

Quoted 2 lines

RAID3/4/5/6 is inherently unsuitable for fast random writes because if a write-read-write cycle required to update the parity.

Nearly all major supercomputers use raid5 with extra spare as well as most database servers.

Can you quantify that bold statement?

I would expect vastly higher levels of RAID than RAID5 on supercomputers, because RAID5 doesn't scale sufficiently. RAID6 is a bit better, but still doesn't really scale. It comes down to data error rates on disks. RAID5 with current error rates tops out at about 6-8TB, which is pitifully small on the supercomputer scale.

Anybody deploying RAID5 on high-performance database servers that are expected to have more than about 1% write:read ratio has no business being a database administrator, IMO.

Then again the fact that I have managed to optimize the performance of most systems I've been called to provide consultancy on by factors of between 10 and 1000 without requiring any new hardware shows me that the industry is full of people who haven't got a clue what they are doing.

Quoted 2 lines

Stock exchange is more into raid10 type clustering,
but those few harddrives that the stock exchange uses, is that relevant?

You're pulling examples out of the air, and it is difficult to discuss them without in-depth system design information. And I doubt you have access to that level of the system design information of stock exchange systems unless you work for one. Do you?

Quoted 9 lines

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

The only actual benefit is decreased latency.

Which is mighty important; so the ONLY interesting type of filesystem for a SSD is a filesystem that is optimized for read and write latency rather than bandwidth IMHO.

Indeed, I agree (up to a point). Random IOPS has long been the defining measure of disk performance for a reason.

I'm always very careful saying a benchmark is holy.

Most aren't, but every once in a while a meaningful one comes up. Random IOPS one is one such (relatively rare) example.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Especially read latency i consider most important.

Depends on your application. Remember that reads can be sped up by caching.

Even relative simple caching is very difficult to improve, with random reads. The random read speed is of overwhelming influence.

20 years of experience in high-performance applications, databases and clusters showed me otherwise. Random read speed is only an issue until your caches are primed, or if your data set is sufficiently big to overwhelm any practical amount of RAM you could apply.

Quoted 2 lines

Quoted 1 line

I look after a number of systems running applications that are write-bound because the vast majority of reads can be satisfied from page cache, but writes are unavoidable because transactions have to be committed to persistent storage.

You're assuming the working set size fits in caching, which is a very interesting assumption.

Not necessarily the whole working set, but a decent chunk of it, yes. If it doesn't, you probably need to re-assess what you're trying to do.

For example, on databases, as a rule of thumb you need to size your RAM so that all indexes aggregated fit into 50-75% of your RAM. The rest of the RAM is used for page caches for the actual data.

To put it into a different perspective - a typical RHEL server install is 5-6GB. That fits into the RAM on the machine on my desk, and almost fits into the RAM of the laptop on typing up this email on.

If your working set is measured in petabytes, then you are probably using some big iron from Cray or IBM with suitable amounts of memory for your application.

Quoted 4 lines

Quoted 2 lines

You cannot limit your performance assessment to the use-case of an average desktop user running Firefox, Thunderbird and OpenOffice 99% of the time. Those are not the users that file systems advances of the past 30 years are aimed at.

Actually manufacturers design cpu's based upon a good analysis of the spec and linpack benchmark. That's how it works in reality.

Again, I'd love to hear some basis of this.

I don't think there is any, outside of the realm of specialized hardware that is specifically designed for linpack. For starters, such a design would ignore the fact that even simple things like the different optimizing compilers can yield performance differences of 4-8x. CPU designers are smarter than to base their CPU design based on linpack throughput.

Quoted 4 lines

If i would generate them the 'stupid manner', which is how about all software works, then it would be harddrive latency bound. Of course there is no budget for SSD's for the generation of it, i explained you my financial status already. So in contradiction to Ken Thompson i have to be clever.

I'm going to assume that you have already read up on file system optimizations, WRT stride, stripe-width and block group size. Otherwise you could find your RAID array limited to the performance of 1 disk on random IOPS.

Quoted 5 lines

So already a year or 10 ago with some others we figured out a manner of generating that's a lot faster and which is not i/o bound but CPU bound and also the CPU instructions needed have been reduced up roughly factor 60.
Yet you know what?
Number of reads is bigger than the number of writes. So it's a few dozen petabyte writes in total and a bit more reads than that. Probably i'll figure out for this run how to turn off caching, as i cache myself in the entire RAM already.

Are you talking about reads that actually hit the disks or reads that the application performs? If the data was recently read/written, then chances are that the reads will have come from caches. Pay attention to your iostat figures.

Quoted 4 lines

Of course i use a relative small amount of RAM whenever possible, because the latency is the CPU always in all calculations and the bandwidth to the RAM. Now when using a small amount of RAM, when that is possible, say a couple of hundreds of MB, the latency within that is always faster than when using the entire gigabytes of RAM that the box has.

I'm not sure what you're talking about here. CPU cache hit rates, maybe?

Quoted 2 lines

Even simple old file systems already can get to the full bandwidth of any hardware, both read and write, as this proces is not random, but has been bandwidth optimized for both i/o as well as CPU.

That's just wrong. It's not about the file system being able to use the full bandwidth of the hardware, it's about the file system reducing the amount of I/O required so the hardware can perform more work with the same amount of physical resources. Unless you were mis-explaining what you mean.

Quoted 3 lines

When the final set has been generated, what will happen with it, is some sort of supercompression to it. Then it'll fit on SSD hardware easily.
Then it will only be used for reads during searches. So all what matters then is the random read latency.

That's a very, very specialized case that doesn't apply to the vast majority of applications.

Quoted 1 line

This is kind of true for most databases which do not fit in the RAM.

Not at all. Not by a long way. While I agree that database reads usually outnumber the writes by a factor of 100:1, most of those reads never hit the disk. For most decently tuned databases, 90%+ of reads are served from caches, and most of the work is performed before even looking at data tables (usually in page caches), as the record sets are resolved from the index data (generally in RAM, unless performance really isn't a concern).

Quoted 1 line

Number of reads is so overwhelming bigger, that basically with SSD's you care most for random read speed of course.

SSDs yield impressively fast boot up times and operation while caches are cold. And page cache latency is still some 2000x faster than SSD latency (50ns vs 100us).

Quoted 3 lines

Now you have a point that the random write speed is important in many applications; however it can be a few factors worse than random read speed, as long as it isn't phenomenal weaker.

Unless your system is tuned to the point where most reads come from page caches.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

I am more interested in metrics for how much writing is required relative to the amount of data being transferred. For example, if I am restoring a full running system (call it 5GB) from a tar ball onto nilfs2, ext2, ext3, btrfs, etc., I am interested in how many blocks worth of writes actually hit the disk, and to a lesser extent how many of those end up being merged together (since merged operations, in theory, can cause less wear on an SSD because bigger blocks can be handle more efficiently if erasing is required.

The most efficient blocksize for SSD's is 8 channels of 4KB blocks.

I'm not going to bite and get involved in debating the correctness of this (somewhat limited) view. I'll just point out that it bears very little relevant to the paragraph that it appears to be responding to.

Don't act arrogant.
To say it in a manner guys with 100 IQ points below me understand;
If you're doing random writes using the 8 independant channels of 4KB you'll hit the full bandwidth of the SSD basically.

Except you don't get 8 channels on your interface to the SSD. All you are talking about here is the fact that the SSD might be using 8 flash chips in RAID0, which is less relevant. The number of channels also varies wildly across products (the current line of Intel X25-M drives has a 10-channel design). But this still doesn't take away from the fact that random writes are difficult for SSDs. Switch off the write caching on your SSD (hdparm -W0) and see what kind of a performance hit you get. Since you are claiming that SSDs don't have issues with random writes, how do you explain that?

The only reason they are better at managing this random write deficiency on the current generation of drives is because they are doing some serious write re-ordering and physical/logical re-mapping to linearize the writes.

Have a look here for more info on this, conceptually if not product-wise:
http://www.managedflash.com/index.htm
If you were right and it wasn't an issue, ingenious hacks like this wouldn't help. While I'm slightly skeptical about the net benefit of this for the latest generation of SSDs (I haven't tried it yet), it is clear that older drives extract considerable benefit from it.

But the original point I was making in the original paragraph this has been spawned from is about how many writes a file system requires to make the data stick, after all the journaling, metadata and superblock writes are accounted for. Essentially, for writing 1000 files, which file system requires fewest writes to the disk. While this may not be an issue for expensive SSDs with good wear leveling, it is certainly an issue for applications that use cheap disk-like media (CF, SD, etc.) that may not have as advanced a wear leveling algorithm in it's firmware, thus making avoidance of unnecessary writes all the more important.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines · Vincent Diepeveen

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Could you explain that, as far as i know modern SSD's have 8 independant channels to do read and writes, which is why they are having that big read and write speed and can in theory therefore support 8 threads doing reads and writes. Each channel say using blocks of 4KB, so it's 64KB in total.

I'm talking about something else. I'm talking about the fact that you can turn logical random writes into physical sequential writes by re-mapping logical blocks to sequential physical blocks.

That's doing 2 steps back in history isn't it?

Sorry, I don't see what you mean. Can you elaborate?

Quoted 1 line

The big speedup that SSD's deliver for average usage is ESPECIALLY because of the faster random access to the hardware.

Sure - on reads. Writes are a different beast. Look at some reviews of SSDs of various types and generations. Until relatively recently, random write performance (and to a large extent, any write performance) on them has been very poor. Cheap flash media (e.g. USB sticks) still suffers from this.

Don't confuse fast random reads with fast random writes.

Quoted 2 lines

if you have some petabytes of storage, i guess the bigger bandwidth that SSD's deliver is not relevant, as the limitation is the network bandwidth anyway, so some raid5 with extra spare will deliver more than sufficient bandwidth.

RAID3/4/5/6 is inherently unsuitable for fast random writes because if a write-read-write cycle required to update the parity.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

So a file system should benefit from the special properties of a SSD to be suited for this modern hardware.

The only actual benefit is decreased latency.

Which is mighty important; so the ONLY interesting type of filesystem for a SSD is a filesystem that is optimized for read and write latency rather than bandwidth IMHO.

Indeed, I agree (up to a point). Random IOPS has long been the defining measure of disk performance for a reason.

Quoted 1 line

Especially read latency i consider most important.

Depends on your application. Remember that reads can be sped up by caching.

I look after a number of systems running applications that are write-bound because the vast majority of reads can be satisfied from page cache, but writes are unavoidable because transactions have to be committed to persistent storage.

You cannot limit your performance assessment to the use-case of an average desktop user running Firefox, Thunderbird and OpenOffice 99% of the time. Those are not the users that file systems advances of the past 30 years are aimed at.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Of course i understand you skip ext4 as that obviously still has to get bugfixed.

It seems to be deemed stable enough for several distros, and will be the default in RHEL6 in a few months' time, so that's less of a concern.

I ran into severe problems with ext4 and i just used it at 1 harddrive, same experiences with other linux users.

How recently have you tried it? RHEL6b has only been out for a month.

Quoted 1 line

Note i used ubuntu.

I guess that explains some of your desktop-centric views.

Quoted 1 line

Stuff like RHEL is more expensive a copy than i have at my bank account.

RHEL6b is a public beta, freely downloadable.

CentOS is a community recompile of RHEL, 100% binary compatible, just with different artwork/logos. Freely available. As is Scientific Linux (a very similar project to CentOS, also a free recompile of RHEL). If you haven't found them, you can't have looked very hard.

Quoted 2 lines

Quoted 1 line

I am more interested in metrics for how much writing is required relative to the amount of data being transferred. For example, if I am restoring a full running system (call it 5GB) from a tar ball onto nilfs2, ext2, ext3, btrfs, etc., I am interested in how many blocks worth of writes actually hit the disk, and to a lesser extent how many of those end up being merged together (since merged operations, in theory, can cause less wear on an SSD because bigger blocks can be handle more efficiently if erasing is required.

The most efficient blocksize for SSD's is 8 channels of 4KB blocks.

I'm not going to bite and get involved in debating the correctness of this (somewhat limited) view. I'll just point out that it bears very little relevant to the paragraph that it appears to be responding to.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, so that the writes happen sequentially anyway.

Could you explain that, as far as i know modern SSD's have 8 independant channels to do read and writes, which is why they are having that big read and write speed and can in theory therefore support 8 threads doing reads and writes. Each channel say using blocks of 4KB, so it's 64KB in total.

I'm talking about something else. I'm talking about the fact that you can turn logical random writes into physical sequential writes by re-mapping logical blocks to sequential physical blocks.

That's doing 2 steps back in history isn't it?

Sorry, I don't see what you mean. Can you elaborate?

I didn't investigate NILFS, but under all conditions what you want to avoid is some sort of central locking of the file system, because if you're proposing all sorts of fancy stuff to the file system whereas you can already do your thing using full bandwidth of the SSD.

It really is interesting to have a file system where you do a minimum number of actions to the file system so that other threads can do there work there. Any complicated datastructure manipulation that requires central locking or other forms of complicated locking will limit other i/o actions.