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

Chris Mason chris.mason at oracle.com
Wed Jan 23 06:01:46 PST 2008


On Wednesday 23 January 2008, myLC at gmx.net wrote:
> 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...
>

I think you're saying that a copy-on-write duplicate is not sufficient for 
video editing.  The thing to keep in mind is that with btrfs COW is done on 
an extent basis, and extents can be small (1MB is small for these files).  
So, you can do the video editing part via cow, slice out the parts you don't 
want, and you'll get that storage back.  It is just a matter of setting the 
max extent size on the file.

>
>  > 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.).

I don't think you can conclude moving the hibernation file is the cause of the 
performance problem.  XP probably frees as much file cache as it can before 
suspend to disk, which means that when you resume you have to seek all over 
the drive to load files back in.    It is entirely possible the new layout is 
less optimal for this workload.

-chris



More information about the Btrfs-devel mailing list