2012/3/1 Ted Ts'o ty...@mit.edu:
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
2012/3/1 Chris Mason chris.ma...@oracle.com:
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
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
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.
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 find-new
On Fri, Mar 2, 2012 at 6:50 PM, Brian J. Murrell br...@interlinx.bc.ca 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
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
find-new
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
On Fri, Mar 2, 2012 at 7:31 AM, Brian J. Murrell br...@interlinx.bc.ca 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
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.png
2012/3/2 Chris Mason chris.ma...@oracle.com:
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:
On Fri, Mar 02, 2012 at 03:16:12PM +0100, Jacek Luczak wrote:
2012/3/2 Chris Mason chris.ma...@oracle.com:
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:
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 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
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 2, 2012 at 1:44 PM, Brian J. Murrell br...@interlinx.bc.ca 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/
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 the
17 matches
Mail list logo
