On Mon, Jan 12, 2015 at 03:40:41PM -0500, Phillip Susi wrote: > I've been investigating why parted's rescue operation is so slow and > it seems that it is largely due to AFFS, so I am trying to understand > it a bit. I notice that it appears to read the first 16 sectors of > the disk ( not the partition or potential partition ) looking for some > sort of "rigid disk" block. Why is this? Wouldn't this prevent the > possibility of having such a filesystem on a gpt partitioned disk, or > a disk with grub installed? Or a loop image? I checked the kernel > affs code and it has a different way of computing the fs block size ( > which seems to be the reason for reading the rigid disk block ). > > Another reason for the slowness is that affs registers 15 different > variants and each one must be probed separately resulting in 15 times > the number of reads. Is it really necessary to differentiate between > all of these sub types in the output of parted print? > > Also where can I find tools for creating such a filesystem for testing > purposes?
I don't know any more than the wikipedia page, I was an Atari guy back then :) But my guess would be that AFFS was never meant to live on a partition, since it is based on and backwards-compatible with, the format they used on floppies. If it is causing that much trouble I wouldn't be opposed to dropping support for it. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
