SliTaz Forum
You are not logged in.
Pages: 1
I've been following this guide for v4, to run it from a USB stick. After hitting a brick wall, I searched the issue before posting here, and I know the reason why I can't login as tux after I've saved rootfs.gz is because the USB isn't formatted to ext3.
I went halfway, I made a new partition on the USB and formatted it to ext2, as is recommended for USB sticks, and tried again. Nope, sorry, same login failure.
So I'm just asking, no Fat32, ok, but why not ext2? I gather that using a journaling filesystem on a USB flash drive will cause it to wear out prematurely. Can I use ext4 and disable journaling? Thanks.
Offline
Journaling will make flash drives wear out prematurely? Sometime I wonder where some of you guys get your information. You'd probably do more damage to it as you would by running defrag every time you start Windows.
Journaling is way more effective than defrag - it just puts the files in the first open space that can fit it rather than appending it to the disk like FAT or NTFS does. That means it requires less disk activity than you normally would on an Windows. That's a good thing.
Anyway, flash drives don't have moving parts and they tend to last a pretty long time. I have one that's nearly 7 years old and it's still running and I've shifted a lot of information on and off it (and formatted it a couple of times to run an OS on it).
And to answer your question: Yes, you could use ext4 - SliTaz 4 uses ext4 if you don't specify otherwise.
Offline
Hi Trixar thanks for your reply. So that's why Windows keeps hammering away at my HDD for no apparent reason, its defragging everything. I'll see about turning that off.
From Wikipedia: "ext2 is still the filesystem of choice for flash-based storage media (such as SD cards, and USB flash drives), since its lack of a journal minimizes the number of writes, and flash devices have a limited number of write cycles." link
Another case for ext2 is that undelete is a bit more of a bitch on ext3 and ext4. link
But it's all good because rootfs.gz writes can be made to work on ext2 after all. Why didn't you just say so? Thanks to mt12345 and kultex for pointing me to the solution in this thread. Add to the boot parameters in Grub4dos menu.lst:
home=UUID TYPE=ext2 autologin
And presto! Just changed some desktop settings, haven't installed any packages yet to see if they will stick, but confidence is high.
Thanks all. Looking forward to getting to know Slitaz.
Offline
You would imagine journaling would make file recovery a little easier el linky, but in practice that's not completely the case. I noted that most of the deleted files were found in the lost+found directory rather than home directory it was deleted from. Disk crawlers like Testdisk's photorec still seems to work without problems though, except it takes a while to scan a whole disk.
Windows does have something called Disk Indexing which makes searching files faster. The downside to it is that it creates disk activity when your not using your system. This is a little different from journaling because it only works for searching, while ext3/4's journal can be used to recover files, find their locations more quickly and keep the disk defragmentation low by fitting files into the nearest space. You kind of lose out on those benefits by saving on a few minor writes (which Windows alone - even without disk indexing - uses more of anyway). I generally find that some bits of Wikipedia is the opinion of the article's author - hell there isn't even a notability link included or [citation needed] for that point in the article. He also didn't mention that most solid state drives have a guaranteed minimum lifetime of 10 years of constant usage. It'll probably last longer than that, but few people would use something that long.
For ext2 drives however, there is a way to defrag them manually using a defrag tool like Shake-fs (which I made a package of here) - just remember to clear your web browser's cache or you may get false positives.
Offline
SSD with 25nm technology have a lifetime of 3000 writes, so really their expected lifetime is a function of their size and how they get written to (latest drives have complex algorithms that will spread the writes intelligently accross the disk, so that the writes does not wear on a particular area of the SSD).
Data will get written in block of 512 KB I believe, so that writing 5K files costs as much as writing a larger file.
Hence a 64 GB SSD that can be written at 200MB/s, and would be written to constantly, would be worn out in 64000 * 3000/200/3600/24 = 11 days.
The average user is believed to write 5 to 10 GB/day ~ 7,5 GB/day.
Suppose x10 (data gets written in clusters and most of my files are small files eg FF cache).
Then my disk will be dead in 64/75*3000 / 365 = 7 years
The factor could be different than 10. I could suspend to disk or increase my need for data writes in the future; so that 7 years for my 64GB SSD is really my best guess.
For your flashdrive the best way to not kill it is not use it, which you wont. They are unexpensive. I would probably use it as ext3, do regular backups, and change it when necessary. I would not use one for the kind of intensive work I do (but would, "on the go").
They do not provide the complex algorithms SSDs have to manage data, which means they will not last anywhere close to an SSD (and assume different price points have different endurance and reliability).
This being said I've had very few sticks that broke, and I am not using my 128 MB 10 years old sticks, because I have 4 and 8GB ones that are much more convenient (and much much faster).
Offline
3000 writes? Really? I'd wear one out in about a week 
Offline
3000 write per cell, yes.... I know it sounds horribly low.
If you can afford the professional grade slc type then they rate 10x to 30x higher than consumer grade mlc type -- they are used in servers, or for the msata internal small drive cache which start appearing with latest windows versions.
Sounds awfully low, but if you thing of a "normal" utilisation with 256 GB SSD then you still have a decent mileage
It also sounds like Slitaz running from memory will also be both faster AND cheaper that on disk, ssd based slitaz -- or rather, for that matter, than on ssd-based ubuntu
Maybe, after all, there is a reason I like Slitaz so much (and want to address >3.5GB Ram )
Offline
Christophe - I saw one of your posts from 6 months ago about ssd / trim / ext4 / where to pass fs options etc
I replaced the failed pata disc on my IBMX31 with a cheap Kingspec16GB SSD [22 GBP] from ebay. My question is related to the above i.e. how to get the best 'lifespan' from this device?
Ive done a full install using ext4, the hd light hardly ever seems to flash. Do I really need to adjust anything?
Thanks!
Offline
you want to enable trim, supported with ext4 only, and disable atime, ie
- add noatime and discard in /etc/fstab (on my ubuntu machine it looks like this: default,noatime,discard)
- you can disable journaling with ext4
ext4 support 3 modes: writeback, ordered, journal mode
Do a search on the internet on how to enable writeback in fstab
I am not a big fan of disabling journals. I have had consistencies issues with ext2 on an unstable system.
For what it's worth, "mount" on Slitaz 4 shows / (formatted ext4) is mounted as ext2.
If i remember, in rcS.conf or whichever script gets executed first: / gets mounted readonly then remounted explicitly as ext2.
That would explain why slitaz was 25% faster on ios (compared to ubuntu on the same machine).
It means you have to check whether / is ultimately behaving as a ext2 or ext4 FS, since ext2 does not support trim. This is one of several reasons i stay away from slitaz at this time (no time to check for sure).
Trim to save on your disk, and is the only way to prevent your disk to become slower and slower because of the way ssd do writes (another way is to regularily backup reformat restore the disk).
In other words, I would investigate what i mentionned above, if I where you,
Hope this helps.
Offline
Pages: 1
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.56 MiB (Peak: 1.77 MiB) ]