On 19/02/2013 18:25, Reindl Harald wrote:
Am 19.02.2013 19:19, schrieb Gordan Bobic:
On 19/02/2013 17:48, Heinz Diehl wrote:
On 19.02.2013, Reindl Harald wrote:
i can not remember when the last ext3/ext4
had 512 bytes blocksize
[....]
Most of the "conventional" harddisks have a sectorsize/blocksize of
512/512. All the newer and bigger WD/Seagate drives and SSDs are using
"advanced format", which means 512/4096.
To support this, there are two factors which must be present:
1. Proper alignment to 4k block boundaries
2. A filesystem on top which supports 4k blocksize
If you use "dd" to raw-copy a 512/512 drive to a newer WD/Seagate or a
SSD, this will result in misalignment (even if your FS supports the 4k
blocksize) causing huge performance loss.
To avoid this, you'll have to create proper aligned partitions on the
new drive first, formatted with a FS supporting 4k blocksize,
and copy the data the "traditional" way, e.g. using cp, rsync and brothers.
To ensure proper alignment it is sufficient to manually partition to 4KB boundaries and then dd individual
partitions over (as opposed to the whole disk in one transfer). Of course, mkfs + [cp | rsync | tar] will be much
more efficient as it only transfers the files, rather than also the empty space
but does not transfer whole RAID setups with all their UUIDs
and detail config and so better wait for SSD's which are not
crippled by get ONE TIME written completly which iw ould
consider as broken hardware
Indeed. Depends on the SSD. USB sticks and SD/CF card based stuff tends
to have wear leveling so poor that you can kill them pretty easily with
this sort of activity. The good ones will do block level deduplication
and compression for you and throw away 0-filled blocks instead of
storing them.
also with dd over ssh the empty space is compressed and not
transferred, with modern CPUs and RC4 cipher this goes up
to 98 MB/second over Gigabit ethernet
The most efficient way to transfer it over ssh with plenty of cpu is
probably using tar, piping through a parallel compressor (pigz, pbzip2,
pxz, ...), and then the revers on the target side ssh command.
before i reinstall the machine eblow whcih exists
more than one time i stay with 2 TB non SSD-disks
and in a few years you can expand the RAID10 to a
spindle with 6x2TB which is fast enough for most
workloads if not all, currently the 4X2 TB RAID10
is reading up to 300MB/sec and writes 150-200 MB/sec
I wouldn't really trust traditional any RAID with disks over 500GB. ZFS
for me, thanks. Otherwise you get bit-rot every time a sector fails (no
way to tell which mirror has the right data in RAID1/10 or whether the
stripe or the parity is correct in RAID5 - you need at least RAID6, and
even then it's very questionable and dependant on the implementation
whether you'll get the right data combination back). Traditional RAID
is, IMO, not really fit for purpose with disks of the size in common use
today.
Gordan
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
