FlashFire XP 32Bit (0.a0) - New Buffering Engine

[butz.tsai]

Reviewers who gave me rejection pointed following issues:
(1) Reliability problem: holding data in buffer may cause file system crash for sudden power failures.

Same issue by built-in write cache on hardware.

(2) The buffering technique is not novel: High-end SSDs are using write-coalescing in the drive already.
--> As the market mature, component cost will drop, and HW solution (on-board write buffer) will be more popular. Therefore FlashFire solution will not be useful at that time.

1.write-coalescing in the drive need more cpu power ,
a flash controller design for low power , should use low end cpu as possible , 8051 may not enough but it really the best processor for low power........ more queue depeth or reorder command all need more cpu power , that mean more electronic power also needed.
2. write-coalescing need DRAM inside the drive , another big unit for an flash controller
not make sense for cheap SSD......current low end SSD all built-in small sram inside IC. no extra DRAM, high end SSD all built-in very small DRAM (16-64MB)........hard to write-coalescing large amount data.

(3) Log-structured File System is better than FlashFire Solution: Log-structured File System can change random writes (small writes) to sequential writes, and thus there will be no performance problem with log-structured file system.
(and so on)

The best solution for SSD , but when ? MS not offer any Log structure file system until now ,

Recently, I implemented new buffering engine, and I am evaluating FlashFire on six SSDs.
- Two Low-end SSDs:HP Mini, ASUS Eeepc1000
- Two Middle-Level SSDs: Kingston ssdNOW V series 64G, RiData Ultra-S 64G
- Two High-end SSDs: OCZ Vertex 60G, Intel X-25M 80G

The tests are being progressed... and until now, the results are very positive.

Looks good , does there any big difference/issue between X86/X64 platform ? XP and 7 ?

[SGuser]

Background:
Tried 0.a0 on my 2 RAID0 SSDs (JMF602b controllers on AMD790GX mobo). The SSDs are tweaked (aligned, 128k RAID cluster, reduced background writes etc) to avoid the weaknesses of JMF602b. This rig has been operating perfectly for 3 months. Typical ATTO scores are 160K-write, 250k-read above 32k transfer sizes. I don't pay much attention to smaller/slower transfer sizes as I formatted in 16k disk clusters.

Test:
1) Booted PC and once disk activties settled, I ran ATTO and got my usual 160k-write, 250k read.
2) Installed 0.a.0, rebooted, disk settled, ran ATTO: Averaged about 72k-write, 210k-read.
3) Disabled 0.a0 with FFcntl, ran ATTO: Averaged about 140k-write, 240k-read.
4) Installed ffire-buffersize, rebooted, ff enabled, ran ATTO: about same score as (3). But 32k to 128k was lower.

Looks like 0.a0 don't quite like my rig. I have also tried earlier versions with negative or little effect. That's fine with me as the rig is already pretty quick without FF, and I have ghosted back to pre-FF baclup. So, everything's cool.

BTW, FF is running great on my 2 netbooks (S101 & 701SD) and the speed up is quite amazing. Thanks for all the great(and free) work.

[SGuser]

Forget to mention.

I am reasonably sure dskcache.exe may have significantly reduced the number of scandisk on start-ups. I think my netbooks have not gotten a single scandisk for the past 2 - 3 months after issuing <dskcache +p c:>. dskcache is freely available and the +p c: parameter adds power protection to WinXP disk cache (which is disabled by default). Go give it a try.

[mimarsinan-1]

That email address doesn't work

Thank you very much for increasing the buffer size. Is 64 MB the maximum buffer size now, or is a bigger buffer configurable now, such as 128 MB or more?

I think all FlashFire needs at this point is:

- prioritizing MFT and registry writes to ensure once a write begins, it is committed in full (I have had many corruptions due to this), instead of cut in half when a power loss or sudden BSOD occurs

OR

- converting all random writes to non-volatile linear writes on-disk (instead of and/or together with the memory buffer) and flushing them into their correct random locations when disk is idle
AND
- if there is still data left in the non-volatile linear disk buffer after a reboot (such as BSOD or power loss), flushing that buffer in full before letting Windows resume with the boot process

If you can contact me somehow (mimarsinan at gmail dot com), I would like to discuss licensing this source code and/or sponsoring its further development.

[zartto]

Thanks for many advises, first.

That email address doesn't work

You can contact me with this address, zflashfire at gmail dot com

Thank you very much for increasing the buffer size. Is 64 MB the maximum buffer size now, or is a bigger buffer configurable now, such as 128 MB or more?

There is no explicit limitation, in this version.
But, my test is not enough...

- prioritizing MFT and registry writes to ensure once a write begins, it is committed in full (I have had many corruptions due to this), instead of cut in half when a power loss or sudden BSOD occurs

Can I ask what is MFT ? (Managed Flash Technology?)
Also, I cannot distinguish registry writes.

Thanks.

[mimarsinan-1]

Some test results:

1. Setting the BufferSize registry value to 7f (hex) works. Interestingly, this actually creates a 248 MB buffer, as reported by the FlashFire Status tool - and not a 127 MB buffer as one might expect. I tested the full buffer size and it works normally as expected.

2. Setting the BufferSize registry value to 80 (hex) or any higher value (128 MB) crashes the FlashFire Status tool. The computer behaves very slowly, so I think one can deduce that the driver is also not working.

Compared to the previous version I was using, having an almost-256 MB buffer is fantastic, and this does wonders to improve the performance of my SSD drive. Thank you very much! The 64 MB buffer in the previous version just ran out too soon, with any kind of serious usage.

I will also run some more tests, buffering large size buffers also, to see if I can improve performance even more.

By MFT I was referring to the Master File Table in NTFS. I have had corruptions in the MFT and also in the registry when I lose power, or the computer BSODs for any reason, while there are pending writes with FlashFire. Unless I am very careful, this means I have to re-image my computer about once a week So for now, I am working around this problem by frequently imaging my system

The product you are referring to, Managed Flash Technology, is unusable as far as I am concerned, for the following reasons:
- Cannot be installed on boot partition
- Migration tools do not really work
- Need to re-install Windows for maximum benefit
FlashFire is an amazing tool, if only because it can be easily (un)installed on ANY system, including the boot partition, and does not require migration or installation from scratch. It takes seconds to install and use. And it really works!

Keep up the great work!!! I think if you are able to somehow solve the corruption problem when a BSOD or power failure occurs - or at least get the corruption risk to the same level as native Windows - FlashFire will be extremely successful.

[Ramon]

I am aware of the task list, but I am still trying to publish my technical paper about FlashFire.
It keeps being rejected.

Zartto,

Have you tried "Software: Practice and Experience" Journal? (http://www3.interscience.wiley.com/jour ... 1&SRETRY=0) (I am also dedicated to research and I know sometimes how difficult is to convince reviewers )

I have published one paper on that Journal and I think this journal could fit very well your practical approach.

Regards

[calzone]

Zartto, is the new version able to run on two disks? It's my standard question about eeePC 901
Happy New Year!

[calzone]

Here is somewhat shocking result of 7F (248MB buffer?) in eeePC 901 disk 1 (4GB)

[Sasha_Beluj]

Can you post plain text of .reg file? Current .reg file seems to be interrupted and doesn't work =(