|
From: Szakacsits S. <sz...@si...> - 2003-04-10 04:02:57
|
On Wed, 9 Apr 2003, Ian Jackson wrote: > > BTW, I strongly recommend, send your purposal for comments, review to the > > linux-fsdevel mailing list > > http://www.kernelnewbies.org/mailinglist.php3 > > I've done that. Thanks. I'll also read/think about it. Only comment now is that the backup boot sector, the last 512 bytes of the partition, isn't strictly part of the NTFS. Nowhere NTFS refers to it. So imaging based on exclusively cluster bitmap isn't enough. > > - must have the consistency check. My experiences from ntfsresize > > I don't have a per-se objection to this, but I don't want to put > anything in the ntfsimage.c file that's not related to the image > stream generation. It's a POW issue. I think it is a requirement before making any image. Partimage doesn't have this, this is one of the reasons I'd never trust it. The other one, it doesn't use the well-tested, widely used libntfs. For me it came free: in the same session both consistency check and imaging are done (except stdout case). So I guess you just use the cluster bitmap. Without validating its correctness it's untrustable for reliable imaging, works for you but not in widespread use. Also don't forget, NTFS is quite complex, has several versions and was reverse engineered. If you get reports that your tool destroyed/lost data, you might want to figure out what went wrong. Some cases I had or were caught before progressing, - inconsistent NTFS - bad RAM - kernel bugs - wrong IDE cable - partitioning tool bug - bugs in code _during_ development > If there's a library function to do it, excellent. Otherwise I'll punt > on that for now. OK, I'll make, actually it's also in progress as part of making the inode/attrib/cluster walking code shared with many callback points for ntfsresize/ntfsmeta/ntfsck/ntfsdefrag/my_ntfsimage and potentially others. Anton, how about if I start ntfsck as well based on the ntfsresize checks? It feels very stupid now, that I must ask people, please run 'ntfsresize -i device' to check your NTFS. > (I'm using `utils_mount_volume'. Maybe, if you want things to do utils_mount_volume is missing things. See mount_volume and after it was called the volume size checks in ntfsresize. The error messages also answer FAQ's what got gone after I added the explanations/guesses to them. > consistency checks, it should be called from there ?) Probably not. But I'd like to have locking there or actually in ntfs_mount. > [sparse files] > ... > Yes, I think it has got worse (from your point of view). Naturally I > think this is an improvement :-). I thought the same for a long time ... until I regularly started to work with sparse files. Users have 30, 80, 200, etc GB filesystems with a couple of MB metadata scattered on them. For debug, regression testing, etc they are highly valuable. I have a couple of GB. I need to cp, tar, bzip2, md5sum, ntfsresize, etc many of them. Frequently time is spent just reading/writing empty buffers You think it's an improvement, so how would you do these? I thought maybe I try LD_PRELOAD a libsparse intercepting libc IO calls if feasible and supporting the only fs providing the needed support, XFS. Szaka |
