Showing posts from January, 2015

Two different definitions of fragmentation

There are two distinct definitions of file fragmentation on a filesystem. 1. The file is fragmented if reading the entire file requires a head seek after the first data block has been read.  This definition mostly concerns read performance on rotational  drives. Head seek is slow, so it is something you want to avoid. If the file is sparse, i.e. has large area full of zeros in it, then the filesystem will not store zeros. Instead, only non-zero start and end of file are stored. From the performance standpoint, that's fine. Filesystem driver will read the first part of the data, then will generate the amount of zeros as required, and continue reading the last part of data without ever making a head seek. If the file contains some metadata (i.e. ReFS page table) embedded in content, that is also fine from performance standpoint. The ReFS driver will read the file data, and at some point the page table will be needed. It conveniently happens that a page table occupies the nex

X-RAID2 with two drives

Just thought I would clarify one misconception about X-RAID2. If there are two identical drives, then the array is in fact RAID1. No, not exactly. The array may be RAID1, but there are cases when there are two (or more) RAID1s, combined by LVM. This happens when a two-disk set is upgraded by replacing two drives with larger ones. If the array never had it's drives replaced, it is indeed a single RAID1.

NAS recovery training

What we see in the support requests is that people have difficulties recovering their (or customers') NASes. For the duration of December 2014, more than half support queries associated with ReclaiMe software were in some way related to a NAS. So we decided to put off filesystems for a while and do a solid course on NAS recovery, starting with initial data collection, through partitioning schemes like FlexRAID or SHR (Synology Hybrid RAID), and to file extraction. This should be available on our training site eventually (hopefully by the end of February).

EXT3 undelete

As you probably know, there are three basic variants of EXT filesystem versus undelete, depending on whether extents and journaling are used. no extents and no journaling - EXT2;  journaling only, but no extents - EXT3; both journaling and extents - EXT4.  Journaling for whatever fancy filesystem development reasons requires inodes to be cleared (overwritten with zeros) when files are deleted. However, we now have an undelete capability for EXT3 (where extents are not used) in our ReclaiMe Pro software. The undelete requires the full scan of the disk to work, and also file names cannot be recovered (because inodes are gone), but otherwise works fairly decent.