public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Miller <miller@techsource.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Maximizing and maintaining fragmentation
Date: Fri, 13 Feb 2004 14:33:27 -0500	[thread overview]
Message-ID: <402D2687.2000005@techsource.com> (raw)

A colleague and I are doing some experiments, and we are attempting to 
model the layout of the filesystem on our server at work.  We're using 
that model because of certain challenges with the very deep directory 
structure.

We are copying about 30GB to one of our personal computers here on the 
LAN and in order to introduce file fragmentation (to simulate what is 
probably the case in the working environment), we are running 3 tar 
pipes at the same time.

(Interesting:  the combination of the disk access and the built-in NIC 
on the ABIT KV7 make the kernel use about 70% of the CPU, and user space 
is using all of the rest.  We're only doing 100 megabit ethernet, so 
what gives?)

Now, since the actual data is proprietary, we want to run a program on 
the data after we've copied it which will scramble the actual file 
contents before we remove it from the building (we are not concerned 
about compressibility).  But we do not want to alter the structure of 
the data on disk in any other way.  If the scrambler were to determine 
the file size of the original file, write out random data of that same 
size, and then copy the new file over the old one, that would likely 
reduce or eliminate the fragmentation.

My proposal is to open and mmap each file and scramble the data by 
writing to the file in virtual memory.  When the file is unmapped and 
closed, I am assuming that the new data will get written to the same 
physical locations on disk as the original file.


IMPORTANT QUESTION:  When writing to an mmap'ed file, will ext3 
rearrange blocks on disk in order to reduce fragmentation, or will it 
leave the blocks exactly where they are, just overwriting the data?


Thanks.


             reply	other threads:[~2004-02-13 19:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-13 19:33 Timothy Miller [this message]
2004-02-14  3:30 ` Maximizing and maintaining fragmentation Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=402D2687.2000005@techsource.com \
    --to=miller@techsource.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox