Another filesystem..
offtopic: why does it take (much) longer to delete files on Linux filesystems than on window$' Fat32/NTFS? Even from Linux deleting from the fat32/ntfs happens quickly, while on ext4/btrs it's like 10-100 times slower.
Phoronix: Samsung Introduces New Linux File-System: F2FS
Announced this morning on the kernel mailing list was F2FS, a new open-source Linux file-system that comes courtesy of Samsung...
http://www.phoronix.com/vr.php?view=MTE5OTY
Another filesystem..
offtopic: why does it take (much) longer to delete files on Linux filesystems than on window$' Fat32/NTFS? Even from Linux deleting from the fat32/ntfs happens quickly, while on ext4/btrs it's like 10-100 times slower.
Perhaps journaling has something to do with it.
I too am rolling my eyes at another FS. Seriously why are all of these new ones being made? We need to get rid of others and combine them with the currently best ones. btrfs is really the only new FS that shouldn't be discarded since it seems to combine every feature of every FS known. Doesn't it even have an option for flash memory?
Unlike lanyardfs, this one actually has a point. It'll maximize the life of the flash.
btrfs will not do that. Any generic fs will not do that.
Trying to maximize flash lifetime is a worthless effort. Try writing a SSD to death withing 10 years.
http://www.xtremesystems.org/forums/...e-25nm-Vs-34nm
No one is ever going to write that much on an SSD on a daily basis that you exceed 1 PB host write.
A very common SSD (Crucial M4) has surpassed 750 TB host write. Spread it over 10 years (3650 Days) and you'd have
to write over 200 GB (the drive itself will have either 128 or 256 GB capacity) per day every day for 10 years and it will still function.
SSDs can take a lot of shit contrary to popular belief.
Last edited by blackout23; 10-05-2012 at 09:24 AM.
I've always found wondoze file deletes to be be incredibly slow. With Linux, you can delete a 500 GB file in a fraction of a second -- erase the inode and ignore the file, which is suddenly and thoroughly deallocated.
Now when you're dealing with MANY MANY MANY files, it can start to take a little longer, because it has to scan through, sort, and delete individually using a recursive algo. This could be more a limitation of the actual delete command than the filesystem itself.
Also; fat32 doesn't use any form of journal. If you want to compare performance of that, try ext2 vs fat or otherwise disable the journal.