Re: BTRFS should increase the hard-link in the same directory limit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



so there are these hundreds of message files, and when one is read, a
new link to The Markfile appears with a similar name as the read file?
Is that right?
if the point is to save inodes by making a directory entry that's a
hardlink to something already existing, why not link to the message
file?

On Sun, Aug 21, 2011 at 5:05 PM, James Cloos <cloos@xxxxxxxxxxx> wrote:
>>>>>> "JF" == John Fremlin <john@xxxxxxxxxxx> writes:
>
> JF> instead of creating a separate inode for each marked message, uses a
> JF> hardlink to a single markfile. This means that there maybe thousands
> JF> of hardlinks to the same inode in a single directory.
>
> And that behaviour is not limited to gnus.  Many workflows use that idiom.
>
> -JimC
> --
> James Cloos <cloos@xxxxxxxxxxx>         OpenPGP: 1024D/ED7DAEA6
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
"The tools expect that they have full, unlimited control of the hardware."
 -- Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux