Kyle Gates posted on Fri, 02 Mar 2012 11:29:40 -0600 as excerpted:
> I set the C (NOCOW) and z (Not_Compressed) flags on a folder but the
> extent counts of files contained there keep increasing.
> Said files are large and frequently modified but not changing in size.
> This does not happen when t
On Fri, Mar 2, 2012 at 1:44 PM, Brian J. Murrell wrote:
> On 12-03-02 08:36 AM, cwillu wrote:
>>
>> Try btrfs sub delete /etc/apt/oneiric, assuming that that's the path
>> where you actually see it.
>
> Well, there is a root filesystem at /etc/apt/oneiric:
>
> # ls /etc/apt/oneiric/
> bin etc
On Fri, Mar 02, 2012 at 02:32:15PM -0500, Ted Ts'o wrote:
> On Fri, Mar 02, 2012 at 09:26:51AM -0500, Chris Mason wrote:
> >
> > filefrag will tell you how many extents each file has, any file with
> > more than one extent is interesting. (The ext4 crowd may have better
> > suggestions on measuri
On 12-03-02 08:36 AM, cwillu wrote:
>
> Try btrfs sub delete /etc/apt/oneiric, assuming that that's the path
> where you actually see it.
Well, there is a root filesystem at /etc/apt/oneiric:
# ls /etc/apt/oneiric/
bin etc initrd.img.old mnt root selinux tmp vmlinuz
boot home
On Fri, Mar 02, 2012 at 09:26:51AM -0500, Chris Mason wrote:
>
> filefrag will tell you how many extents each file has, any file with
> more than one extent is interesting. (The ext4 crowd may have better
> suggestions on measuring fragmentation).
You can get a *huge* amount of information (prob
I set the C (NOCOW) and z (Not_Compressed) flags on a folder but the extent
counts of files contained there keep increasing.
Said files are large and frequently modified but not changing in size. This
does not happen when the filesystem is mounted with nodatacow.
I'm using this as a workaround
On Fri, Mar 02, 2012 at 03:16:12PM +0100, Jacek Luczak wrote:
> 2012/3/2 Chris Mason :
> > On Fri, Mar 02, 2012 at 11:05:56AM +0100, Jacek Luczak wrote:
> >>
> >> I've took both on tests. The subject is acp and spd_readdir used with
> >> tar, all on ext4:
> >> 1) acp: http://91.234.146.107/~difrost
2012/3/2 Chris Mason :
> On Fri, Mar 02, 2012 at 11:05:56AM +0100, Jacek Luczak wrote:
>>
>> I've took both on tests. The subject is acp and spd_readdir used with
>> tar, all on ext4:
>> 1) acp: http://91.234.146.107/~difrost/seekwatcher/acp_ext4.png
>> 2) spd_readdir:
>> http://91.234.146.107/~di
On Fri, Mar 02, 2012 at 11:05:56AM +0100, Jacek Luczak wrote:
>
> I've took both on tests. The subject is acp and spd_readdir used with
> tar, all on ext4:
> 1) acp: http://91.234.146.107/~difrost/seekwatcher/acp_ext4.png
> 2) spd_readdir: http://91.234.146.107/~difrost/seekwatcher/tar_ext4_readir
On Fri, Mar 2, 2012 at 7:31 AM, Brian J. Murrell wrote:
> I seem to have the following subvolumes of my filesystem:
>
> # btrfs sub li /
> ID 256 top level 5 path @
> ID 257 top level 5 path @home
> ID 258 top level 5 path @/etc/apt/oneiric
>
> I *think* the last one is there due to a:
>
> # btrfs
I seem to have the following subvolumes of my filesystem:
# btrfs sub li /
ID 256 top level 5 path @
ID 257 top level 5 path @home
ID 258 top level 5 path @/etc/apt/oneiric
I *think* the last one is there due to a:
# btrfsctl -s oneiric /
that I did prior to doing an upgrade. I can't seem to f
cwillu wrote (ao):
> > While developing snapper I faced similar problems and looked at
> > find-new but unfortunately it is not sufficient. E.g. when a file
> > is deleted find-new does not report anything, see the reply to my
> > mail here one year ago [1]. Also for newly created empty files
> > f
On Fri, Mar 2, 2012 at 6:50 PM, Brian J. Murrell wrote:
> Is 2010-06-01 really the last time the tools were considered
> stable or are Ubuntu just being conservative and/or lazy about updating?
The last one :)
Or probably no one has bugged them enough and point out they're
already using a git s
>> Perhaps all that is unnecessary: rather than doing the walk, why not
>> make use of btrfs subvolume find-new (or rather, the syscalls it
>> uses)?
>
> While developing snapper I faced similar problems and looked at
> find-new but unfortunately it is not sufficient. E.g. when a file
> is deleted
On 12-02-26 06:00 AM, Hugo Mills wrote:
>
>The option that nobody's mentioned yet is to use mixed mode. This
> is the -M or --mixed option when you create the filesystem. It's
> designed specifically for small filesystems, and removes the
> data/metadata split for more efficient packing.
Cool
On Thu, Mar 01, 2012 at 05:54:40AM -0600, cwillu wrote:
> There doesn't appear to be any reason for the scratch file to exist at
> all (one can build up the hash while reading the directories), and
> keeping a scratch file in /etc/ is poor practice in the first place
> (that's what /tmp and/or /va
2012/3/1 Chris Mason :
> On Wed, Feb 29, 2012 at 11:44:31PM -0500, Theodore Tso wrote:
>> You might try sorting the entries returned by readdir by inode number before
>> you stat them. This is a long-standing weakness in ext3/ext4, and it has
>> to do with how we added hashed tree indexes to d
2012/3/1 Ted Ts'o :
> On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote:
>>
>> Yep, ext4 is close to my wife's closet.
>>
>
> Were all of the file systems freshly laid down, or was this an aged
> ext4 file system?
Always fresh, recreated for each tests - that's why it takes quite
much t
18 matches
Mail list logo
