Propose your solution
Attachments
No attachments.
Duplicates
Comments
on5sl
(Idea reviewer)
wrote on the 25 Jan 09 at 13:22
|
|
|
exFAT from Microsoft is optimized for portable flash drives, and misses features like file permissions and so on...
So exFAT wo'nt be a EXT4 killer, but still we should be aware for other filesystems from Microsoft who could beat the great performance of EXT4.
|
|
on5sl
(Idea reviewer)
wrote on the 25 Jan 09 at 14:10
|
|
|
@AndrewLuecke
ow, i thought is didn't support it...Well then, whats is a good solution then? Create a new filesystm only for SSD?
|
|
|
People who have a hard disk ssd uses ext2 because there is not Journal file system.
ext3 decreases life of a hard disk ssd.
|
|
on5sl
(Idea reviewer)
wrote on the 26 Jan 09 at 10:57
|
|
|
@AndrewLuecke
Well then, maybe it's a good idea then to use the LogFS in the future when is completely stable? I think developing another filesystem will be difficult cause of time and developers?
|
|
r0g
wrote on the 28 Jan 09 at 00:19
|
|
|
@AndrewLuecke -
What the hell has wear-levelling got to do with anything?
AFAIK you can't even buy an SSD that doesn't do automatic wear-levelling in hardware. Rewriting the same logical sector will not rewrite the same hardware sector, this is NOT a software issue.
Also modern SSDs have so much write endurance it would take you years, if not decades of pounding it at FULL SPEED to deliberately wear it out. Bad write endurance is a myth as I point out in my solution above, read the article I mention in it if you doubt me.
|
|
|
The most important thing for SSDs is to avoid unnecessary writes. This can not be fixed by the filesystem alone, you also have to configure the whole system in a proper way (such as mounting /tmp as tmpfs) and use clever applications (which does not fsync too often like Firefox).
|
|
r0g
wrote on the 31 Jan 09 at 03:50
|
|
|
@Andrew...
"Assuming we can write to a single 1kb sector continuously at 80MB, that means 25SECONDS!!! This assumes a good controller..."
You can't though, that's what hardware wear leveling does - it abstracts the drives ABI sectors from the actual hardware 'sectors'. You can repeatedly tell it to overwrite the same sector and it will tell you it has but underneath all that it has just overwritten the least worn block of flash it can find and has remapped the 'sector' you see to point at that instead.
Disk-controller schmisk-controller - wear leveling is not a software issue with modern SSDs. Writing less data overall will maybe extend the life of your SSD from a very long time to a very VERY long time at the cost of extra driver logic and cycles but you gain nothing from futzing with "where" the data is 'physically' written - there is no physical "where" with SSD.
|
|
|
My fstab:
/dev/sda2 / ext3 defaults,noatime 0 0
proc /proc proc defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
/dev/mmcblk0p2 swap swap defaults 0 0
|
|
walkeer
wrote on the 9 May 09 at 12:02
|
|
|
Hust a few notes:
1) fragmentation actually IS problem even on SSD, because sequentional read is much higher than random read on SSD, not as much as on classic HDD bud it is still a major difference.
2)internal wear levelling every modern SSD (CF,SD,SSD) have causes internal fragmentation, invisible to OS or controller, which causes huge performance problems, because then writing in sequent causes basicly random write, which is far most the slowest operation SSD do. There is no simple solution for this yet, except whole disk full erase from time to time. for more on this google "ssd internal fragmentation".
3)ssd internal fragmentation can be kind of avoided by writing only larger amounts of data and completly avoiding writing small amounts, such as journal or database. For SSD I would recomend using Ext4 without journal, users reports huge read and write benefit from ext2. Noop scheduler also helps alot.
|
|
TuxHHG
wrote on the 14 Jan 10 at 16:45
|
|
|
Anyway using ext4 with logging on desktop, thinkpad (m-tron mobi) and on my eee. Nothing could be uglier than minutes of full fsck, i remember 30min on a 2gb desktop after power loss. Atomic commit is a must.
Using this fstab here:
UUID=shortened / ext4 noatime,barrier =0,nobh,commit=100,errors=remount-ro 0 1
I vote for a bunch of changes that disable things that mostly are not neccesary. Who really needs a full span of logfiles with rotate on a netbook?
|
Post your comment
|
