On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:

lynn wrote:

...

Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.

If you have a spare partition, you could copy /home over there and mount that.

No, the whole disk is one partition:( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2014-07-02 at 11:55 +0200, jdd wrote:

Le 02/07/2014 11:50, lynn a écrit :

...

...

...

Can I make /home a partition? Without repartitioning? If someone can

...

No, the whole disk is one partition:(

so what do you mean by "make a home partition"?

Almost, '...make /home a partition...'.

you can reduce the present partition from a live dvd and create an other for /home, but all is some sort of repartitionning

OK L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2014-07-02 at 12:34 +0200, Bernhard Voelker wrote:

On 07/02/2014 11:50 AM, lynn wrote:

...

On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:

...

lynn wrote:

...

Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.

If you have a spare partition, you could copy /home over there and mount that.

No, the whole disk is one partition:(

You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].

[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home

Notes: a) Loop-mounting is of course a bit slower than a native disk. b) The sizes of the dd(1) command above may need to be adjusted. c) The mv(1) command above may have to be tweaked to match all directories there (or for omitting lost+found). d) You'd have to adapt /etc/fstab to mount /home automatically on boot.

You didn't tell why you want /home on a separate file system, so I can't judge if the above suffices your needs.

No, sorry. I have, for my sins, to get some sort of failover for our domain file server. Having failed so badly with dfs, I'm going to try drdb. The test boxes I have have the sync data in /home but /home is a folder. Your loop mount is looking good. Does it count as a drdb block device thingy? Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2014-07-02 at 08:09 -0400, Greg Freemyer wrote:

On July 2, 2014 6:48:10 AM EDT, lynn wrote:

...

On Wed, 2014-07-02 at 12:34 +0200, Bernhard Voelker wrote:

...

On 07/02/2014 11:50 AM, lynn wrote:

...

On Wed, 2014-07-02 at 11:25 +0200, Per Jessen wrote:

...

lynn wrote:

...

Can I make /home a partition? Without repartitioning? If someone can reply with an acronym, I think I've got it. But the documentation doesn't make it easy.

If you have a spare partition, you could copy /home over there and mount that.

No, the whole disk is one partition:(

You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].

[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home

Notes: a) Loop-mounting is of course a bit slower than a native disk. b) The sizes of the dd(1) command above may need to be adjusted. c) The mv(1) command above may have to be tweaked to match all directories there (or for omitting lost+found). d) You'd have to adapt /etc/fstab to mount /home automatically on boot.

You didn't tell why you want /home on a separate file system, so I can't judge if the above suffices your needs.

No, sorry. I have, for my sins, to get some sort of failover for our domain file server. Having failed so badly with dfs, I'm going to try drdb. The test boxes I have have the sync data in /home but /home is a folder. Your loop mount is looking good. Does it count as a drdb block device thingy? Thanks, L x

Drdb? I assume you mean drbd? Distributed - replicated- block device

My superior suggested 'drdb' (sic). Thank you so much for this comment.

I think a loop mount will work for that, but it may fail your testing where real disks / partitions / logical volumes would pass.

It seems that yast has a tool to resize partitions. I wonder how reliable that is? I just tried booting a vm with kde. Resized it. Lost everything. Maybe it just doesn't work for vms. Thanks again, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2014 01:03 PM, Carlos E. R. wrote:

On 2014-07-02 12:34, Bernhard Voelker wrote:

...

a) Loop-mounting is of course a bit slower than a native disk.

I think I read this was no longer the case. :-?

I don't have numbers, but a loop-mount is just another level of indirection via the file system the backing file is stored in. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2014 01:31 PM, Carlos E. R. wrote:

But, in theory, an operating system can create a table of the sectors used by the loop file, and use that table instead of calling the filesystem libs to access the file. The file itself is static, it doesn't change in size nor location, at least while mounted: thus you really do not need to access the filesytem structures.

If the file is not fragmented, then it should be as fast as a real partition.

That's a nice trick. I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd wrote:

Le 02/07/2014 15:29, Bernhard Voelker a écrit :

...

That's a nice trick. I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption.

you can have any linux filesystem on loop device, but you need to create at first the file with the total size, wich is not bery practical for hudge partitions

Maybe you could use "truncate" to create a sparse file? -- Per Jessen, Zürich (18.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-07-02 15:29, Bernhard Voelker wrote:

On 07/02/2014 01:31 PM, Carlos E. R. wrote:

...

But, in theory, an operating system can create a table of the sectors used by the loop file, and use that table instead of calling the filesystem libs to access the file. The file itself is static, it doesn't change in size nor location, at least while mounted: thus you really do not need to access the filesytem structures.

If the file is not fragmented, then it should be as fast as a real partition.

That's a nice trick.

Please remember that mine is an educated guess. I /did/ read that swap files are as fast as a real partition, since some version, and I /think/ I read that it also applies to loop files. I don't have confirmation on those, but, based on the theory above, I believe they do. I would have to test it, though.

I'd guess that it doesn't work with all file system types, as this assumes that the underlying file system doesn't somehow move the data along. I'm unsure if any does, but e.g. via - I know, a bad choice - NFS, the loop module couldn't rely on this assumption.

I suppose that the module can find that out. It is all part of the kernel, so if they decide to add that facility, they can add the needed features everywhere as needed :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-07-02 16:12, James Knott wrote:

On 07/02/2014 07:31 AM, Carlos E. R. wrote:

...

If the file is not fragmented, then it should be as fast as a real partition.

How often are files fragmented? I thought the file systems used in Linux were fragmentation resistant.

Resistant, yes, but not immune. fsck tells you the amount. I have seen Linux machines heavily fragmented. Look: nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ # See that 62.6%? That's heavy fragmentation. The disk belongs to a multimedia device that runs Linux (kernel 2.4.21), on an ext2 partition. To totally avoid fragmentation, you have to assign the full space for each file at the instant of creation, and separate files one from another sufficiently so that they can grow. When the disk gets quite filled, the strategy fails. It is possible to move about files while the system is running, if designed carefully. The easiest is to move unused files on iddle system periods - but I don't know of any operating system doing it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2014-07-02 at 11:57 -0400, Greg Freemyer wrote:

On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <> wrote:

...

Resistant, yes, but not immune. fsck tells you the amount. I have seen Linux machines heavily fragmented. Look:

ext4 uses a max of 128 MB block extensions. For large files that are pre-allocated the individual block extensions should be the full 128 MB if possible. It is unlikely all the block extensions will be contiguous from what I understand.

In that particular example, most of the files are 65 MB, with matching index files of about 3 to 5 KB, on an external disk via USB, and it is ext2 (not 2 nor 4, and not a choice; the alternative is FAT). It is a multimedia box of limited cpu power. I just gave it as an example of a machine where heavy fragmentation occurs. On normal Linux machines, the percent is about 2, IIRC. For instance: Telcontar:~ # fsck -f /dev/sdc9 fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information a_test2: 230470/1313280 files (0.1% non-contiguous), 3297636/5242880 blocks Telcontar:~ # - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO1J2kACgkQtTMYHG2NR9XhpACfasIw+gOv6dcT5AxlYrLZHe4d bJUAn2Q+W5dst8imB/0VyDQ3/bITYOx7 =sI1+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2014-07-02 at 12:03 -0400, Greg Freemyer wrote:

On Wed, Jul 2, 2014 at 11:15 AM, Carlos E. R. <> wrote:

...

To totally avoid fragmentation, you have to assign the full space for each file at the instant of creation, and separate files one from another sufficiently so that they can grow. When the disk gets quite filled, the strategy fails. It is possible to move about files while the system is running, if designed carefully. The easiest is to move unused files on iddle system periods - but I don't know of any operating system doing it.

I'm not quite sure what you're saying. e4defrag will defrag an extent based filesystem (as opposed to a block based filesystem like ext2). It does it with the filesystem online.

Ah, that's good news :-) Progress :-) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO1KI0ACgkQtTMYHG2NR9XtDQCeNxxfNQCXbjMalZ5rv68tuh96 3O8AnRYY3/fHkrXMOG5ew1CoHufrbQ5r =lOgB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Bernhard Voelker writes:

You could create a file system in a (huge) file [1][2], loop-mount it somewhere [3], move /home/* to there [4], umount it [5], and mount it (still with -o loop) on /home [6].

[0] export IMG="/somewhere/home.img" [1] dd if=/dev/zero of=$IMG bs=1G count=100 [2] /sbin/mkfs.ext4 -F $IMG /mnt [3] mount -o loop $IMG /mnt [4] mv /home/* /mnt [5] umount /mnt [6] mount -o loop $IMG /home

The "loop" kernel module also must be loaded- it is no longer loaded by default. To have it automatically loaded at boot time, one can put: ,---- | loop `---- in /etc/modules-load.d/local.conf. Charles -- "On a normal ascii line, the only safe condition to detect is a 'BREAK' - everything else having been assigned functions by Gnu EMACS." (By Tarl Neustaedter)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/07/14 13:15, jdd wrote:

a solution, may be, could be to use a btrfs filessyetem and manage internal separation for /home

but I never tried this so don't know if it works

http://fr.wikipedia.org/wiki/Btrfs

jdd

btrfs comes with lots of warnings that it is experimental. Nevertheless, I am trying it out here, and have not had any problems yet. ;-) You can convert an existing ext3/4 filesystem to btrfs: # btrfs-convert /dev/sdx The existing data is stored in /ext2_saved which can be deleted once you are happy with running a btrfs system. This folder is there in case you want to revert back to extfs. Once you delete it, you've burnt your bridges... Then rename /home to eg. /home_old Create a newsubvolume: btrfs subvolume create /home Copy/move the contents of /home_old into /home Delete /home_old *** Disclaimer: I am an amateur/hobbyist whiling away my retirement, and cannot vouch that the above procedure is failsafe. It _has_ worked several times without failure (yet) here. *** Bob - -- Bob Williams System: Linux 3.11.10-17-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.13.2 Uptime: 06:00am up 3 days 20:14, 5 users, load average: 0.08, 0.04, 0.05 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO0H18ACgkQ0Sr7eZJrmU7DSACfZ6UWzCVGPovx/vhEvzIsLKtt UkMAniAh/c+qsMnfpW4qAG3ehN5dYCrg =IUjW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org