gparted

[Blaze]

Hamza, i know it - gparted/0.9.0/src/slack-required
My list of dependencies need for run gparted in Poerteus.
Others dependencies does not need.

[Hamza]

need for run gparted
Yes, that is true. But to have the better experience of GParted in Porteus. You need to have all deps. If one dep is missing, you can't have the better experience.

An example,
You can use slackyd without gnutls pkg. but if this package is not installed, you will have an error and you won't be able to have a better experience with Security Check of Packages in slackyd.

I understood what you mean.

[francois]

lately, I've become partial to using fdisk and mkfs instead of gparted or kde partition manager. For partitioning flash media, it helps to know which sector you are starting and stopping on.

Is there a precise strategy that we should know?

[Ahau]

A precise strategy? Sort of I'll put more detail into a future howto, but briefly:

The most important thing is to align your partitions to match the page size of your flash device. Page sizes are typically 2,4,8, or 16KB. Fdisk allows you to select the first and last sector of a partition (I haven't been able to find a way to do this in KDE partition editor, and haven't tried very hard in gparted, so maybe it's possible there).

Sectors are 512bytes, the first sector is sector 0. KDE partition editor (and I'm guessing gparted as well) typically reverts your drive to a 255 heads / 63 sectors per track geometry and starts your first partition on sector 63 (the first sector on the second track of the first head -- sectors 0-62 are used for the MBR and wasted space). 63 sectors is 31.5 kilobytes, which sets your partition to be out of alignment by half a kilobyte in all instances (later partitions are hit and miss, where the partition editor seems to decide on a sector around the MB limit you provide it). I suggest starting your first partition on sector 64, 2048, or 8192 instead. Sector 64 would put you on an alignment for any page size up to 32KB; 2048 or 8192 is more likely to align your partition to the start of an erase block (these vary in size depending on your device, 1, 2, or 4 MB are common in modern media -- aligning to an erase block might have some advantage, but not as much as aligning to page size). Each partition further down the stick should start on a multiple of 32KB at least (if not 8192 sectors, or 4MB).

To set the partition, you'd start with a blank drive, unmounted e.g. sdc. Run fdisk on it:

fdisk /dev/sdc

type p to see the existing partition table
type d to delete any partitions that are misaligned
type n to create a new partition, and enter the first and last sector (e.g. 8192 and 4095999), then you can create your next partition using 'n' as well and your next sector counts (e.g. 4096000 to the end of the drive).
type w to write the changes

Now, if you go back in and try to format these drives with KDE partition editor (and, probably gparted as well), it will realign your partitions, and we don't want that. Mkfs on the other hand, won't do so.

mkfs.vfat /dev/sdc1
mkfs.ext4 /dev/sdc2

Now, you have a 1996MB FAT32 partition on the front of the drive, and the remainder is ext4.

[francois]

And if I may asked, what are the benefits of such strategy in a nutshell?

[Ahau]

Your flash device will operate more quickly and maybe last longer. Another advantage is that fdisk and mkfs are included in Porteus by default, so you don't need gparted

I'm still trying to grasp all of the details involved, but this is how I see it:
The drive cannot write anything smaller than a single page at a time. It takes the same amount of time to write a full page as it does to write a fraction of a page. Writing two pages takes twice as long as writing to one.

Data is sent by your OS to your flash drive in 4KB chunks (aka blocks -- most filesystems use 4096 byte blocks by default). If you have a 4 KB page size on your drive, but your partition starts in the middle of a a page, then every time your OS sends a 4KB block of data to the device, it will have to spread this data over two pages, doubling the amount of work it takes to write that block to disk.

My drive has a 16KB page size (4 blocks). When it is in alignment, it is 10% to 25% faster when writing than when it is out of alignment. It makes sense, then (though I don't know this for sure), that it can write 4 blocks of data to a single page when it is aligned, but when it is out of alignment, it has to split every fourth block of data across to a new page, reducing it's efficiency.

Sorry for hijacking this thread

Posted after 26 minutes 3 seconds:
In reading the gparted manual, it looks like there is an option that allows you to align your partition to a MiB boundary rather than to a cylinder. This would provide the benefits mentioned above, while allowing users to format their partitions from a GUI instead of the CLI. It's been a while since I used gparted hehe

[francois]

Thanks for the answer.

This is no hijacking. It is more a the modern way of transmitting information. Connectivity thru hyperlinks.

Let's say that your hyperlink was just a little bigger than usual