WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: picore documents and tutorials  (Read 1166 times)

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 6853
    • My Community Forum
Re: picore documents and tutorials
« Reply #15 on: February 11, 2017, 11:32:18 AM »
Suggestions for persistence:
A) Create a total of FOUR partitions
     1) MSDOS/BOOT (~40mb is what we use here, starting at the beginning as opposed to 1MB in.)
     2) EXT2 labeled tcopt (~100mb is ours, but that's due to a large amount of custom static files)
     3) EXT2 labeled tchome (This depends on usage and storage needs IF needed at all*)
     4) EXT2 labeled tce (The remainder of the storage drive)
* For any partitions you don't need, such as home in many cases, simply scratch it from the above list


Never ever use ext2.
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline patrikg

  • Full Member
  • ***
  • Posts: 235
Re: picore documents and tutorials
« Reply #16 on: February 11, 2017, 02:24:13 PM »
I think you could have ext3 and ext4 with out the default journal system.
If that's the cause of you selecting ext2.

When creating/formatting the drive you could just add...
Code: (bash) [Select]
sudo mkfs.ext4 -O ^has_journal /dev/mmcblk0p2
Or you could use tunefs to disable the journal.
I think the first is the best options.
I think you couldn't change when you using the drive, haven't tried my self.
Code: (bash) [Select]
sudo tune2fs -O ^has_journal /dev/mmcblk0p2

And can be listed by.
Code: (bash) [Select]
sudo tune2fs -l /dev/mmcblk0p2 | grep features
« Last Edit: February 11, 2017, 02:30:26 PM by patrikg »

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 6853
    • My Community Forum
Re: picore documents and tutorials
« Reply #17 on: February 11, 2017, 07:07:57 PM »
Why to use a non journaling file system?
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline patrikg

  • Full Member
  • ***
  • Posts: 235
Re: picore documents and tutorials
« Reply #18 on: February 12, 2017, 01:00:32 AM »
It has to do with the nand technology.
To minimize the amount of writes to the nand disc.

I think, then dealing with the nand technology to reduce and get the best of all worlds, is to
use the file systems that have the correct way of doing stuff to the nand tech.
I don't know if ext4 has that support yet.

Every one is talking about another file systems when dealing with nand discs.
I am not the best guy to talk about this, have using ext2 for my Guruplug for long time in a sandisc usb thumb drive and it's working very well.

Here is a some good text on the web:
http://free-electrons.com/blog/managing-flash-storage-with-linux/
http://elinux.org/images/d/de/Managing_nand_flash_elce.pdf
https://www.lip6.fr/public/2012-11-15_Boukhobza_Flash_Final.pdf



Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 6853
    • My Community Forum
Re: picore documents and tutorials
« Reply #19 on: February 12, 2017, 01:38:33 AM »
You can refer several articles, bologs, what ever you want. Bee practical. During 10 years using USB sticks and SD cards with ext4 file system it never happened to me that one of them died because of too wear out. But in every two month I would have loose all of my work without journaling on ext2. Thats all.

So, your advices are welcome. But please, not in the piCore documents and tutorials section, where using ext2 file system is strongly discuraged.
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline centralware

  • Full Member
  • ***
  • Posts: 234
Re: picore documents and tutorials
« Reply #20 on: February 12, 2017, 10:10:43 PM »
@Béla: PatrikG is correct, EXT2 was chosen (years ago) as the default file system due to the lack of journaling/indexing to limit write calls to flash based media.  Not having a single TF die within a decade sounds like a blessing!  In the same decade, we've likely melted no less than 100 USB/SD/uSD cards (our means to dispose of them when they begin failing).  Mind you, for sensitive content we use USB Flash media in addition to storage hard drives for redundancy, but considering factory specs for both types of media AND the failure rates for both types we've endured personally, the easiest way to prove/disprove the concept is to monitor mmc0 write states with a persistent home/opt directory and then run the SD card through an SD testing application and see for yourself the numbers and then compare them against the lifetime expectations the factory sets out.  (I imagine compiling a kernel a few times located in /opt/kern#.#.# should do the trick of giving the card a litte mileage :) ) This information would be FACTORY level...  not a blog or a rumor.  (One would "think" the people who build these chips might have a clue?  Though I've met some who don't! :) )

Back in the day, the rule of thumb was "...1,000 writes per byte of storage multiplied by the total amount of bytes available, subtract 5% for error correction bytes (we use a 2% model) and you'll have a basic idea as to how many written bytes, maximum of storage the card will endure before failing or before being considered unsafe..."  This math was done based on averages of how much content was written within a day's time for each workstation utilizing these cards/chips.

For our development clients (whose projects are uploaded onto flash based media for editing or review and random-dd-written afterward for security):
The brands of USB storage we've purchased: 14 USB2 and 3 USB3 lost since 05/2010
The brands of uSD storage we've purchased: 43 uSDHC and 7 uSDUHS lost since 05/2010
(which we use more frequently)
A few of these were due to physical damage (ie: USB connectors wearing/breaking) but at least 97% are due to disposal if/when flash block failure reaches 2% or exceeds the math above within 10% without detected failure.
Note: Since 2010, the number of lost hard drives has more than doubled compared to 2000-2009 regardless of file system.  I have 80+GB Y2K IDE hard drives still in operation which have outlasted 1+TB SATA3 drives which were less than a couple years old. They truly don't make things like they used to.

@PatrikG: The ^has_journal switch - I will be looking into this throughout the week.  Thank you.

Offline Captain.Midnight

  • WikiUser
  • *
  • Posts: 7
Re: picore documents and tutorials
« Reply #21 on: February 13, 2017, 06:12:21 PM »
Well, couldn't you just sh  t (missing letters are 'o' and 'u' --maybe)
Finally decided that only fear and good-judgment were holding me back until I told myself that I would be using non-volatile data (i.e. easy to replace) to start with anyway and put piCore on my rpi a while ago. Remembering that no matter what keys I pressed would not cause the of some cute and furry species I started playing around with different boot codes and as far as I can tell, the world did not end. I really don't know what I was worried about. Everything so far is working just fine.

Sorry for joking around so much but I'm just coming out of my annual major depressive episode and I'm over-doing it a bit.