4 ms·

I've used FAT32, and yeah. I guess I got lucky. > Also, I've seen ext* filesystems just as badly fragmented as NTFS ones in similar environments. What kind of

I've used FAT32, and yeah. I guess I got lucky. > Also, I've seen ext* filesystems just as badly fragmented as NTFS ones in similar environments. What kind of environment is that? I've rewritten terabytes of data over the same blocks, and never had any issues.

dspillett 9y ago
> rewritten terabytes of data over the same blocks It isn't about the amount of data throughput or the reuse of blocks: it is how files are allocated space as they grow, particularly when there is concurrent activity, and how free space fragments as files shrink or, more likely, are removed. > What kind of environment is that? Busy near-full write-heavy multi-user file servers particularly. Multitasking exacerbates the "how files grow" issue, multiple users exacerbates both, and multiple concurrent users multiplies the issue further, being near full means that data fragmentation countermeasures are circumvented because due to worsened free-space fragmentation (all the space left is in small units). Ignoring a few pathological cases (that are usually unrealistic thought experiments), if the filesystem never gets particularly full then neither NTFS nor ext* are likely to fragment significantly. But in the circumstances mentioned above both are just as likely to. Their key mechanic for avoiding data fragmentation (keeping some free space after files where possible to allow for growth) is very similar, other technicalities where they vary more widely (like storing small objects in directory structures directly or the MFT) have an effect, but a much smaller effect than that attributable to the methods they share. Of course even some near-full multi-use volumes aren't going to fragment significantly at the filesystem level. If a volume is hosting large database files then they are likely to be reasonably contiguous from the filesystem's point of view and fragmentation issues within the data files is massively more significant. Also if most of your concurrent users are only reading (perhaps a media archive system maintained my a small team, perhaps one person, or just at most one person at any given time usually, but accessed by many?) they can be ignored from a fragmentation PoV (readers aren't going to affect data layout unless you have active writers and some exotic MVCC arrangement going on at the filesystem level).

dspillett 9y ago

> rewritten terabytes of data over the same blocks It isn't about the amount of data throughput or the reuse of blocks: it is how files are allocated space as they grow, particularly when there is concurrent activity, and how free space fragments as files shrink or, more likely, are removed. > What kind of environment is that? Busy near-full write-heavy multi-user file servers particularly. Multitasking exacerbates the "how files grow" issue, multiple users exacerbates both, and multiple concurrent users multiplies the issue further, being near full means that data fragmentation countermeasures are circumvented because due to worsened free-space fragmentation (all the space left is in small units). Ignoring a few pathological cases (that are usually unrealistic thought experiments), if the filesystem never gets particularly full then neither NTFS nor ext* are likely to fragment significantly. But in the circumstances mentioned above both are just as likely to. Their key mechanic for avoiding data fragmentation (keeping some free space after files where possible to allow for growth) is very similar, other technicalities where they vary more widely (like storing small objects in directory structures directly or the MFT) have an effect, but a much smaller effect than that attributable to the methods they share. Of course even some near-full multi-use volumes aren't going to fragment significantly at the filesystem level. If a volume is hosting large database files then they are likely to be reasonably contiguous from the filesystem's point of view and fragmentation issues within the data files is massively more significant. Also if most of your concurrent users are only reading (perhaps a media archive system maintained my a small team, perhaps one person, or just at most one person at any given time usually, but accessed by many?) they can be ignored from a fragmentation PoV (readers aren't going to affect data layout unless you have active writers and some exotic MVCC arrangement going on at the filesystem level).