[Btrfs-devel] 3 thoughts about important and outstanding features - cont.

myLC at gmx.net myLC at gmx.net
Wed Jan 23 00:38:34 PST 2008


First of all, thank you for your helpful replies! =)

The idea of creating a modified copy-on-write duplicate is
not bad. For videos this would mean that you could, for
instance, skip over the ads, while in practice they still
remain inside the file.
I believe this is already a preferred way of handling
things, since it is easy to implement within the
application.

Video editing, however, often means to liberate yourself of
a few gigabytes or putting them together (which can take
hours, were it could & should take only a few seconds).
 From a programmer's point of view the present situation
seems rather frustrating. Things haven't changed that much
since the old Datasette went out of order...
This will even be more uncomfortable in the near future,
with harddrives being slowly replaced by RAM (Flash, FE, M-
RAM, etc.). In case of Flash-RAMs, the "art" of reading in
and writing it back out instead of making in-place
modifications, also means a reduced lifetime of the media...

As for XFS, I'm currently using it - as it makes life
somewhat easier (xfs-dump and such).
XFS knows "sparse files". This is mostly useful for
databases or for mmap'ed applications firing their
calculation results into vast (and mostly empty) areas -
which is very simple and yet efficient...
However, that's no help when it comes to the problems
mentioned above. >:-[
(Although XFS has the nifty feature of guaranteed I/O rates,
which could come in handy for DVB-devices - but that's a
different story.)


 > Different disks do different things (including inverting
 > where block 0 lies).

Yes, of course - I know that. However, it is rather easy to
find out which tracks are the faster ones and where it
becomes slower. Usually you can also tell it by the model-
string. There are only a few possibilities anyhow.
My point was that the difference is SO IMMENSE that it
should be worth thinking about it. We're not talking about
something around 5% or so...
For instance I made the mistake of defragmentating my
Windows-XP partition (NTFS) - utilizing a real
defragmentation program of course (XP's leaves the files
fragmented in a mostly arbitrary fashion;-).
The program shoved the hibernation file (which has to be on
the system partition) towards the hub, the result being a
suspend to disk/reawake now taking twice as long as before
(big p.i.t.a.).

The filesystem is free to put the files where it wants to.
Even the most sophisticated algorithm probably still fades
compared to shear knowledge of an educated bipod.
My guess is that you already have various "special" files
and hence attributes to indicate such things. Adding
attributes indicating a certain preference (location) of a
file shouldn't be that difficult if I'm not mistaken. The
yield can be enormous though - point being: it should be
worth a thought...


Again, thanks for you expert notions! >:O}
                                             LC (myLC at gmx.net)




More information about the Btrfs-devel mailing list